Это только когда с округлением накосячишь))

Посоветуйте фрейворк или тул для следующей задачи
1) Есть пачка микросервисов с неплохим REST API
2) Пока не хочется стоить свой DataPool/Lake/DWH со сбором и актуализацией данных.
3) Есть желание строить отчеты, которым нужны данные из нескольких MS

Если продукт А приносит 100 выручки, обходится в 80, мы вкладываем 20 в разработку продукта Б, то я считаю это CapEx вот почему. Если бы мы забрали эти 20 из организации в виде прибыли и инвестировали в другую организацию, где создали бы продукт Б, это было бы CapEx. Вы согласитесь? Но внутри одной организации мы имеем эквивалентную ситуацию - забираем прибыль генерируемую А и вкладываем в Б. Значит это тоже CapEx. Такие вещи как "внутри" или "во вне" организации не должны влиять, иначе попадает смысл этих понятий, которые введены не для бухгалтерского учёта, а для анализа инвестиций в том числе. Продолжу пример, теперь продукт Б стал приносить 100, обходится 80, а А, к тому моменту стал приносить 80 и обходится 80, чтобы быть в 0 и не влиять на последующую логику. В общем ROI продукта А было, согласитесь, ведь на деньги от А мы создали Б. Но если это учили как OpEx, то получается возврата инвестиций с А не было. Теперь с Б, если расходы на него были учтены как OpEx  А, получается Б обошёлся в 0 и его ROI стремится к бесконечности, что неправильно.

Консолидировать придется данные все равно. Или Data Lake, или полноценное DWH в зависимости от аппетита.

Хотя In memory решения есть, сейчас подумал, но думаю будет надёжней и проще положиться на ETL и обработку в некой интегрирующей данные базе с учётом найма и ротации людей в реалиях рынка. Нанять с SQL проще

Подумай каков будет онбоардинг

Однако, спасибо вам за указание на позицию IFRS, я действительно это не читал и почитаю. Если есть ссылка, которая подводит ближе, буду признателен.

ETL подразумевает доступ прямой к базе? или extract делать из API?

Можно. ETL не подразумевает с какого уровня вы берёте, подразумевает перекладывание с одного места а другое ИМХО

В общем, я бы сказал так надо затащить данные куда-то и там построить отчёты. Если решить надо попроще, сделайте просто табличек. Это будет тяжело поддерживать когда-то, но запустите быстро. Если надо основательно, тогда тащить в стейджинг, перекладывать в дэйьта волт, строить витрины по кимбалу ваши ключевые слова. Могу порекомендовать пару книг.

это все понятно. хотелось получить легковесное решение. может хотя бы на время, пока не будет ясно что же мы в итоге хотит от этих отчетов.

Дмитрий, не понял, в чем point)).

Если вы свою уникальную управленку у себя строите -- определяйте сами, как считаете нужным!

Если же вам надо публиковать отчетность, или просто с внешним финансовым миром общаться -- тогда придётся использовать стандарты. Иначе creative accounting.

Это как justice vs. law. Учет -- это про закон.

Ну а мы не для инвесторов и собственников считаем эти капексы, опексы и рои в конечно счёте разве?

И да, Capex не для анализа инвестиций! Хотя по ходу любые цифры учёта могут быть использованы, включая обсуждаемые.

Ну тогда вам придётся считать по стандартам, к этому и веду.

Но что-то не так, посмотрите я привел пример почему разработка продукта не должна быть OpEx

Мы неправильно посчитаем ROI продукта с таким счётом

Нет, это просто ваш пример. Roi можно считать очень по разному.
В capex вообще тупо балансовая стоимость фигурирует.

ROI разве не от EBITDA и CapEx считается?