Центры затрат и проекты в ERPNext: как разделить аналитику, чтобы отчёт по объекту не врал

Cost Center в ERPNext отвечает на вопрос «кто и где тратит» и живёт годами, Project отвечает на вопрос «на какой объект» и живёт до сдачи работ. Ошибки начинаются, когда центр затрат заводят на каждый объект. Ниже: как разделить измерения, где их ставить в документах и как найти потерянный объект в отчёте.

Cost Center и Project в ERPNext: два измерения, два разных вопроса

В документации ERPNext сказано прямо: не заводите Cost Center на каждый короткий проект или на каждого клиента, используйте Project, контрагента или другое измерение учёта, если оно точнее описывает анализ. Я это подтверждаю практикой: самые кривые отчёты по объектам, которые мне приходилось разбирать, получались там, где центр затрат был заведён под каждый объект. Дерево центров разрасталось, часть центров оставалась без движения, а прорабы выбирали «на глаз».

Разница простая. Cost Center это место ответственности: подразделение, площадка, бригада, филиал. Он нужен, чтобы понять, какая часть компании тратит и приносит деньги, и строится деревом: группы для организации иерархии, конечные (негрупповые) центры для проводок. Project это конкретный объект с датами, задачами, табелями и собственными итогами затрат. Подробнее про задачи и Гант у нас есть отдельный материал, а здесь мы говорим только об аналитике. Продукт, в рамках которого мы настраиваем это для заказчика, описан на странице ERPNext под ключ.

В документации по Accounting Dimensions добавлено важное уточнение: ERPNext уже трактует Cost Center и Project как измерения. Поэтому в отчётах и в контроле бюджета они стоят наравне с теми измерениями, которые вы создаёте сами. Это же даёт и обратный эффект: если нужен третий срез (например, этап работ или заказчик), его можно добавить новым измерением, а не плодить центры затрат. Одно ограничение: новое измерение действует только на будущие операции, старые документы задним числом не размечаются. | | Cost Center | Project | |---|---|---| | Вопрос | Кто и где тратит | На какой объект | | Срок жизни | Годы | До сдачи объекта | | Структура | Дерево с группами | Плоский список с задачами | | Примеры | Монтаж фасадов, Склад, Офис | Фасад корпуса А, Фасад корпуса Б | | Что считает | Затраты и результат подразделения | Затраты, часы, маржа по объекту |

Как разделить аналитику: что заводить центром затрат, а что проектом

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

Если расход общий, и его нужно разнести между несколькими центрами, в v15 для этого есть документ Cost Center Allocation: в нём задаётся основной центр, дата начала действия и таблица процентов. Система проверяет, что сумма процентов равна 100, и что основной центр не входит в таблицу разнесения. В нашей базе знаний этот механизм назван «Distributed Cost Center»; в коде v15 такого DocType я не нашёл, актуальное название Cost Center Allocation. Настройте его заранее и проверьте на тестовом проведении.

Разумное исключение из правила «центр на объект не заводим»: площадка как долгоживущая единица. Если у вас есть постоянный склад или производственная база, это центр затрат, потому что он живёт годами и обслуживает много объектов. В одном из сценариев нашей базы аналитика построена так: объект это Project, этап это Task, площадка это Cost Center, материал это Item, статья это Expense Account. Это не противоречит правилу: площадка здесь постоянная, а не разовый объект.

И ещё два технических ограничения кода, которые стоит знать до разметки. Центр затрат с проводками нельзя превратить в группу: система ответит ошибкой. Центр, участвующий в Cost Center Allocation, тоже нельзя превратить в группу. То есть реорганизовать дерево после начала работы дороже, чем продумать его заранее.

• Cost Center: подразделения, площадки, бригады, филиалы
• Project: каждый объект со своими задачами и сроком
• Дополнительное измерение: этап, заказчик, статья бюджета
• Общие расходы: Cost Center Allocation по заданным процентам

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

Измерение должно пройти всю цепочку: заявка на материалы, заказ поставщику, счёт поставщика, списание материалов на объект, проводка. Каждое звено, где его забыли поставить, это дыра в отчёте. В строке счёта поставщика (Purchase Invoice Item) есть три поля, которые определяют судьбу расхода: Expense Account, Cost Center и Project. Если Project пуст, затрата попадёт в общие расходы, и по объекту её не будет видно, сколько бы вы ни фильтровали отчёт.

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

Журнальные проводки (Journal Entry) это отдельный случай. В строке проводки есть поля Cost Center и Project, но чтобы контроль бюджета сработал, проект должен стоять у строки с дебетуемым счётом расходов. Для списания материалов на объект (Stock Entry типа Material Issue) нужны проект и счёт расходов. Это те точки, где измерение теряется чаще всего, и они показаны красными метками на схеме после раздела.

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

Три ошибки разметки, из-за которых отчёт по объекту расходится

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

Ошибка вторая: Project не проставлен в строках счёта поставщика. Симптом: отчёт по объекту пуст или занижен, а затрат у проекта нет, хотя закупки шли. Причина: проект указали в заявке, но в счёте строка осталась без него. Действие: в проведённом счёте поля Project и Cost Center в строках допускают правку после проведения (в метаданных v15 у них стоит allow on submit), но чтобы изменение попало в проводки, нужно убедиться, что они переписались: сверьте отчёт General Ledger и при необходимости воспользуйтесь документом Repost Accounting Ledger. Это поведение зависит от версии, проверьте его на тестовом счёте.

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

Таблица ниже повторяет дерево решений из инфографики. | Симптом | Причина | Действие | |---|---|---| | Нельзя выбрать центр, ошибка при проведении | Центр под каждый объект, счета заданы не полностью | Перейти на Project, довести настройки счетов | | Отчёт по объекту пуст | Project не проставлен в строках счёта | Проставить проект, проверить проводки | | Бюджет не срабатывает на проводке | Нет Project в строке дебета | Указать проект в строке Journal Entry |

Budget по Project и по Cost Center: что контролируется, а что нет

Документ Budget создаётся против Cost Center или Project (в v15 это два штатных значения поля Budget Against; проверка в budget.py проходит и по пользовательским измерениям учёта, но их появление в форме проверьте на своей версии). В нём указываются счета расходов, лимиты и режимы Warn, Stop, Ignore. Контроль денежный: он видит рубли по счёту расходов. Как это настраивается и где молчит, мы подробно разбирали в статье про лимиты на объект, а здесь важно другое: бюджет против проекта работает только на тех документах, где проект проставлен.

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

Контроль количества («не более 12 тонн по спецификации») Budget не делает, это отдельная доработка. И для сводного взгляда после работ есть отчёт Budget Variance Report: бюджет, факт и отклонение по проектам или центрам за выбранный период. Он строится по проведённым данным, поэтому потерянный проект в документах отразится и на нём.

Как «Фасад-Норд» собрал отчёт по трём фасадам без дублей

Условный пример, цифры вымышленные. Фирма фасадных работ «Фасад-Норд», 16 рабочих мест: директор, два прораба, снабженец, бухгалтер и бригады монтажников. Три объекта одновременно: навесной вентилируемый фасад административного здания, остекление торгового павильона и ремонт фасада жилого дома. Изначально в системе были 11 центров затрат: три из них на объекты, четыре на подразделения и ещё четыре «временные» от прошлых лет.

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

Что нашлось при проверке (условно). Около 40 строк счетов поставщиков за два месяца не имели проекта: это были закупки расходников, которые снабженец оформлял «пачкой». Мы разнесли их по объектам вручную, проверили проводки по General Ledger и добавили в регламент правило: счёт без проекта не проводится, пока не указана причина. После этого отчёт по каждому объекту сошёлся с Excel директора, а главное, перестал зависеть от того, кто как «помнит» расходы.

Итог. Директор видит затраты по объекту, не открывая бухгалтерию, а подразделения сравниваются между собой по центрам. Конкретной экономии я не обещаю: результат дают порядок в справочниках и дисциплина ввода, а не сама программа. Как выглядит отчёт по объекту и как проставляется проект по цепочке, покажем на демостенде erp-demo.itfresh.ru по запросу.

Где такая разметка не поможет

Разметка измерений не заменяет бухгалтерский учёт. Регламентированный учёт в российской компании остаётся в 1С, а управленческие срезы ERPNext это отдельный контур; как соединить их без двойного ввода, описано в нашем материале про локализацию Odoo и обмен с 1С, принципы мастер-данных там сопоставимы. Если вы выбираете систему и сомневаетесь, есть сравнительный материал о том, какую систему учёта на Linux выбрать.

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

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