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

Це також одна з п’яти точок, де картина витрат у 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 проєктів.

Звітні витрати проєкту є результатом налаштувань системи. Кожна з описаних вище проблем — нульова ставка, сторнована фактична витрата субпідрядника, непроведений інтеграційний журнал — створює цифру, яка виглядає коректною, але занижує фактичні витрати. Почніть із двох перевірок: перевірте прайс-листи собівартості щодо ролей, категорій і продуктів, які фактично використовуються, та відкрийте представлення робочого простору інтеграції, щоб побачити, які дані так і не потрапили до Finance. Якщо обидві перевірки не виявлять проблем, показнику маржинальності можна довіряти.