Британская консалтинговая компания подписывает 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.

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