Британська консалтингова компанія підписує statement of work на £400 000. Двоє з чотирьох людей, які виконують проєкт, працюють у сестринській компанії в Польщі, а третій є залученим спеціалістом, який щомісяця виставляє рахунок. Усі знають, що проєкт прибутковий. Але ніхто не може сказати, наскільки саме, аж до шести тижнів після його завершення, коли фінансовий відділ закінчує звіряти внутрішньогрупові нарахування з табелями робочого часу та рахунками постачальників. Така затримка — це не проблема звітності, а результат рішення, прийнятого під час налаштування платформи. У цьому матеріалі розглядається, що саме ERP для професійних послуг має моделювати для компанії, яка працює через мережу юридичних осіб і партнерів, і які рішення не можна відкладати.

Лондонська компанія підписує statement of work. Люди, які виконують роботу, можуть перебувати в Кракові, Порту або працювати в партнерській компанії, яка пов’язана з клієнтом на один контракт через іншу сторону. Для британських консалтингових та аутсорсингових компаній це звичайна модель виконання робіт, але саме її найскладніше коректно представити у фінансовій системі.

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

У результаті такої звірки отримують показник, на основі якого вже ніхто не може діяти. Коли він стає доступним, проєкт або вже завершений, або зайшов надто далеко, щоб змінювати його ціну.

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

Dynamics 365 Project Operations постачається у трьох варіантах розгортання: Project Operations Core, Project Operations Integrated with ERP та Project Operations for manufacturing.

Project Operations Core зупиняється на proforma invoicing. Proforma-рахунок перевіряється та передається до окремої фінансової системи для обробки, а робота з витратами охоплює базові витрати, пов’язані з проєктами. Власний опис Microsoft цього варіанта передбачає використання сторонньої ERP для податків із продажу, валютних курсів, відшкодування витрат та непроєктних витрат. Для компанії, яка вже веде фінансовий облік в іншій системі та потребує управління ресурсами, планування і фіксації робочого часу, це цілком обґрунтований варіант.

Інтегроване розгортання замикає цей цикл. Воно додає налаштовувані профілі витрат і доходів проєкту, правила обліку незавершеного виробництва та нарахувань, а також визнання доходу за проєктами, яке Microsoft документує як таке, що відповідає IFRS. Виставлення рахунків працює на базі механізму податків із продажу та валютних курсів, що залежать від дати, у Dynamics 365 Finance.

Це перша справжня точка вибору під час підбору ERP для професійних послуг, і це набагато чіткіше питання, ніж зазвичай формулюють постачальники: чи має фінансовий облік бути в тій самій системі, що й виконання проєктів, чи поруч із нею? Для компанії, що працює через мережу юридичних осіб, відповідь визначає все подальше, оскільки витрати між юридичними особами та визнаний дохід потрапляють до одного бухгалтерського реєстру лише в інтегрованому розгортанні. Компанії, яким не потрібен повний фінансово-операційний контур, можуть вести проєктну роботу в Dynamics 365 Business Central, де вона розміщена в модулі Projects.

Термін Microsoft для спільного виконання робіт — lending and borrowing legal entity, тобто юридичні особи, що позичають і залучають ресурси. Юридична особа, яка утримує контракт із клієнтом, є borrowing entity, а юридична особа, співробітники якої виконують роботу, — lending entity. Ресурси lending entity безпосередньо реєструють робочий час і витрати за проєктами, що належать borrowing entity, і саме цей механізм відрізняє мережу, яка звітує безперервно, від тієї, що щомісяця проводить звірку.

Грошові потоки регулюють два налаштування. Записи витрат використовують прайс-лист собівартості borrowing entity, тому в обліку юридичної особи, що виконує роботу, відображається ставка, за якою контрактна юридична особа оплачує послуги, а не ставка, придумана наприкінці періоду. Маржинальність, яку утримує юридична особа, що виконує роботу, формується через transfer price — трансфертну ціну, визначену для кожної borrowing legal entity із датою набуття чинності. Це перетворює зміну ставки на датований запис, а не на повторне узгодження в електронній таблиці.

Після цього внутрішньогрупове виставлення рахунків працює як ланцюг проведень. Lending entity створює внутрішньогруповий рахунок клієнту вручну або за допомогою періодичного пакетного процесу, а його проведення створює відповідний рахунок постачальника в статусі pending у borrowing entity. Витрати потрапляють до проєктного субреєстру borrowing entity після проведення цього рахунка постачальника. Перш ніж усе це запрацює, для кожної пари юридичних осіб потрібно налаштувати внутрішньогруповий облік. Це варто підняти ще на етапі визначення обсягу проєкту: скільки таких пар існує і хто підтримуватиме їх у міру зміни структури групи.

Для директора з виконання проєктів внутрішньогрупове виставлення рахунків створює ланцюг записів із визначеними відповідальними на кожному етапі. Натомість воно вимагає заздалегідь і свідомо визначити трансфертну ціну для кожної пари юридичних осіб.

Залучені спеціалісти є іншою частиною мережі, і зазвичай вони приходять через закупівлі, а не через управління ресурсами. Створений у Dataverse субпідрядний контракт генерує замовлення на закупівлю у Finance; кожен табель робочого часу або витрата, зареєстровані субпідрядником, створюють product receipt; коли надходить рахунок постачальника, працівник кредиторської заборгованості зіставляє його із зареєстрованим часом і витратами за допомогою тристороннього зіставлення. Управління субпідрядниками перестає існувати паралельно із записом про проєкт і стає його частиною.

Ліцензування залежить від типу ресурсу. Субпідрядник, налаштований як bookable resource типу User, вводить власний робочий час і потребує дійсної ліцензії. Типи Contact та Account можна планувати та бронювати на проєктах без надання їм доступу до системи. Для компанії, яка щокварталу залучає сорок спеціалістів і хоче, щоб десятеро з них самостійно вносили дані в систему, ця відмінність безпосередньо впливає на бюджет.

Одне документоване обмеження варто обговорити ще до укладання контрактів: фіксована ціна субпідрядних контрактів не підтримується для сценаріїв resource та non-stocked у Dynamics 365 Project Operations. Рядки субпідрядних контрактів базуються на кількості або виконаній роботі. Компанія, яка купує у партнерів пакети робіт із фіксованою ціною, має узгодити спосіб їх представлення під час проєктування рішення, а не під час UAT.

OntargIT побудувала шар проєктного обліку для Room 8 Group, міжнародної компанії з аутсорсингу розробки ігор, на базі Dynamics 365 Finance and Operations: проєктний облік, виставлення рахунків за проєктами, фінансова консолідація, визнання доходу на момент завершення та інтеграція між Jira і Dynamics 365, щоб запис про виконання робіт і фінансовий запис описували одну й ту саму роботу. OntargIT також працює з іншого боку цієї моделі, виконуючи 17 спільних проєктів як субпідрядний партнер Inciper Limited, британської консалтингової компанії з Dynamics 365.

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