Фактический расход с нулевой ставкой проводится без ошибки. Он попадает в фактические расходы проекта и бухгалтерский регистр, не добавляет ничего к расходам и создает впечатление, что проект является более прибыльным, чем он был на самом деле. Такое поведение задокументировано, а не является дефектом — именно так система работает, когда прайс-лист не может определить ставку.

Это также одна из пяти точек, где картина расходов в Dynamics 365 Project Operations зависит от настроек, а не от того, сколько команда фактически потратила. В этой статье рассмотрена каждая из таких точек — резервные варианты ценообразования, сторнирование расходов субподрядчиков, передача данных в Finance — и определена конкретная проверка, которая позволяет закрыть каждую из них, чтобы отчетность по расходам проекта отражала полную сумму.

Dynamics 365 Project Operations доступен в трех типах развертывания: Project Operations Core, Project Operations Integrated with ERP и Project Operations for manufacturing. Те, кто внедрял систему до переименования, знают их как lite, resource/non-stocked и stocked/production order. Выбор обычно делается исходя из лицензирования и объема внедрения — и именно он определяет границы учета расходов еще до того, как кто-то откроет прайс-лист.

Integrated with ERP охватывает самый широкий набор каналов: полный учет расходов с распознаванием чеков, выставление счетов клиентам и признание дохода по проектам. Core имеет только базовый учет расходов, то есть простые расходы, зафиксированные по проекту и утвержденные ответственным за проект, и не поддерживает признание дохода. Два канала отсутствуют по определению, а не из-за неправильной настройки. Все приведенное ниже предусматривает Integrated with ERP и отдельно отмечает случаи, когда граница отличается для Core.

Каждый фактический расход требует ставки себестоимости, и система определяет ее из прайс-листа себестоимости, выбранного по дате операции и валюте. Для времени система сопоставляет Role, Resourcing Company и Resourcing Unit со строками цен для ролей. Если для этой комбинации ничего не найдено, система отбрасывает измерение с наименьшим приоритетом и выполняет поиск повторно, продолжая до тех пор, пока не будет найдена соответствующая строка. Только когда строка с ценой для роли вообще не найдена, ставка по умолчанию становится нулевой.

Для расходов и материалов такого механизма допуска нет. Одна неудавшаяся попытка сопоставления по Category и Unit или по Product и Unit приводит к нулевой ставке — постепенного резервного поиска нет. Материал ведет себя так же, если соответствующая строка цены использует метод ценообразования, отличный от Currency amount, поскольку Dynamics 365 Project Operations поддерживает только Currency amount для материалов, использованных в проекте.

Фактический расход с нулевой ставкой все равно проводится. Ничто его не блокирует и ничто не помечает; проект просто отражает меньшие расходы, чем было понесено на самом деле. Это самая распространенная причина, по которой отслеживание расходов проекта незаметно занижает фактические расходы.

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

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

В этом процессе выставления счетов поставщиками определяют три условия. Необходимо включить функцию обработки фактических расходов субподрядчиков в Feature management. Фактические расходы можно сопоставить только со строками счета поставщика, содержащими ссылку на строку субподряда; статус проверки продолжает отслеживаться для строк, не имеющих такой ссылки, но фактические расходы невозможно связать с ними. Кроме того, субподряды с фиксированной ценой не поддерживаются для сценариев resource/non-stocked, что исключает выставление счетов поставщиком по этапам в таком развертывании.

Фактические расходы проекта в Dataverse еще не являются бухгалтерскими записями. Периодический процесс Import from staging table находит фактические расходы, которые еще не попали в интеграционный журнал Project Operations, и создает для каждого из них отдельную строку журнала. После этого кто-то должен провести этот журнал. Пока оба шага не завершены, расход существует на операционном уровне, но не отражается в бухгалтерском регистре.

Насколько детализированной будет картина в бухгалтерском регистре, зависит от параметра Period unit, который группирует строки журнала по дням, месяцам, годам или в один журнал для всех операций. Годовая группировка является допустимой настройкой и приводит к тому, что бухгалтерские данные отстают от данных проекта на несколько месяцев.

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

Project Operations содержит рабочее пространство интеграции, созданное именно для решения этой проблемы. Представление Missing actuals показывает расходы, обработанные в Finance, для которых отсутствуют соответствующие записи из Dataverse; представление Missing journal lines показывает расходы и счета поставщиков, которые успешно синхронизировались, но для которых не была создана или проведена строка интеграционного журнала. Обе проверки должны выполняться по расписанию с назначенным ответственным, а не оставаться предметом расследования раз в квартал.

Есть один нюанс отчетности, который заслуживает большего внимания, чем обычно получает. Вкладка Tracking в проекте показывает только расходы на труд — расходы на материалы и другие расходы не включаются в отображаемые там данные. Если воспринимать ее как общую сумму расходов проекта, расходы будут занижены, а модель Power BI должна напрямую использовать фактические расходы проекта, а не воспроизводить это представление.

Надежное отслеживание расходов проекта здесь относится к зоне ответственности IT, поскольку каждая из описанных выше проблем является следствием настройки или синхронизации, а не бухгалтерской ошибкой.

OntargIT внедрила Dynamics 365 Finance вместе с Project Operations для Encore Business Solutions в Канаде, охватив бухгалтерский учет проектов, управление ресурсами и управление проектами. Для Room 8 Group, компании, специализирующейся на аутсорсинге разработки игр, OntargIT автоматизировала бухгалтерский учет проектов и выставление счетов по проектам и интегрировала Jira с Dynamics 365, чтобы данные о выполнении работ попадали в финансовый учет. OntargIT является Microsoft Solutions Partner for Business Applications с 2009 года и реализовала более 150 проектов.

Reported project cost is a configuration outcome. Every failure above — a zero rate, a reversed subcontract actual, an unposted integration journal — produces a number that looks valid and understates spend. Start with two checks: run the cost price lists against the roles, categories and products actually in use, and open the integration workspace views to see what never reached Finance. If both come back clean, the margin figure can be trusted.