Комментарии 28
А почему тогда не Access с его формами и отчетами?
Access это SQL база данных. Создать финансовую модель на SQL не так уж и просто. Поддерживать такую модель еще сложнее. За лесом селектов и джойнов не будет видно, что мы тут вообще считаем (самих формул).
Access это база данных входящая вофис, и которая вполне может брать данные из excel таблицы, и визуализировать средствами Access
В этом случае модель вычислений остается в Эксель со всеми перечисленными выше трудностями. Для визуализации есть более подходящие инструменты (tableau и т.д.).
В том-то и дело, что access это не просто SQL база. Это полноценный инструмент для разработки приложений. С формами, с отчетами, с логикой.
Модель вычисления можно разложить между эксель и access
эксель может просто хранить данные в удобном виде, в табличке
access, как SQL база, может работать с разными табличками, включая лежащие в excel, в access, csv и др.
Просто главное что я имел ввиду — access и excel это уже продукты в готовом интегрированном виде, и не нужно использовать еще что-либо сверху, если нужно сделать gui
Модель вычисления можно разложить между эксель и access
эксель может просто хранить данные в удобном виде, в табличке
access, как SQL база, может работать с разными табличками, включая лежащие в excel, в access, csv и др.
Просто главное что я имел ввиду — access и excel это уже продукты в готовом интегрированном виде, и не нужно использовать еще что-либо сверху, если нужно сделать gui
Если система всё равно рассчитана на технически грамотного аналитика, в чём для него проблема загнать данные в Oracle/MSSQL/Postgres и анализировать там всей мощью SQL? А вообще продвинутый вариант электронных таблиц с генератором отчетов есть у MS в составе Office и называется Access.
Не совсем понимаю, какая у вашего продукта ЦА.
Не совсем понимаю, какая у вашего продукта ЦА.
Я начал этот проект именно после нескольких таких проектов на Оракл и SQL. Это конечно возможно, но очень трудоемко. Таблицы, формы ввода, много кода. Понять что делает SQL или PL/SQL запрос через пару месяцев разработки очень сложно. Модель табличного процессора позволяет решить проблему в десятки раз быстрее и элегантнее.
Я — ЦА, руководитель нескольких проектов. Меня укачивает от обилия ERP/CRM/Task-managment систем. Мечтаю всё в Excel перевести, но останавливали проблемы описанные автором в статье (кнопки, dropdown-меню).
На текущий момент самое близкое решение моих проблем — Notion/Airtable, но на чужих серверах не комфортно.
Очень жаль, что не open source, но хорошо, что On-premise есть.
Подождите, но ведь и кнопки, и пользовательские элементы, и табличные функции, и VBA — всё это есть уже в Excel и отлично документировано. Мне кажется, ТС сражается с ветряными мельницами.
На счёт ветряных мельниц Вы не правы. Подобная многомерная таблица действительно удобное расширение обычной. Когда надо по-быстрому набросать какую-то считалку каких-то данных, часто возникает ситуация «эх, здесь бы добавить слой с таким же поведением, но другими данными!»
звучит интересно но есть нюансы. В компании, где я работал, экономисты, по сути, работали как раз с excel таблицами. Чтобы перейти с существующих таблиц на это решение требуется тоже немалый труд, вполне сопоставимый, как я понимаю, с переходом на sql решения.
Возможно, что я ориентируюсь на свои usecase. Обычно это либо уже анализ консолидированных данных и для этого вполне пригоден Excel, либо поисковые задачи типа «а давайте поиграем вот это комиссией и посмотрим, сколько мы заработаем, изменив её на +0.05% для некоторых клиентов, а профиль клиентов определим, сделав исторический анализ по N миллионам клиентских транз в геополовозрастной разбивке и разложением на (M,S) групп по суммам и регулярности покупок прошлых периодов и у которых предположительно есть кредиты». Тут Excel вообще не помогает :)
Ну на самом деле SQL далеко не всегда удобен для анализа. С моей точки зрения даже редко удобен. А продвинутая аналитика, когда Excel уже не хватает — это R+RStudio, либо Python + Jupyter.
Как человек, который делает в Экселе те самые финмодели на дохренаста показателей, могу сразу сказать, что никакая альтернатива не «взлетит». Не потому, что она будет хуже для работы, а потому, что она не будет стандартом. Почти всегда, когда я делаю модель, она потом идет на проверку сначала заказчику, а потом в банк или госструктуру, предоставляющую финансирование. И если специалисты этого банка или госструктуры не увидят знакомых им табличек, они просто не станут смотреть то, что я наваял. Поэтому только Эксель.
Ну а если нужно что-то сделать для себя лично, то тут и так инструментов полно. Можно запустить Джупитер, можно открыть R-Studio, можно тот же Access использовать (хоть и не люблю я его), но это все для себя. А для заказчика: Эксель и желательно без макросов/VBA, без вариантов (хотя вру, есть один клиент, которому принципиально нужно в Таблицах Гугл, потому что они не пользуются продуктами Microsoft).
Ну а если нужно что-то сделать для себя лично, то тут и так инструментов полно. Можно запустить Джупитер, можно открыть R-Studio, можно тот же Access использовать (хоть и не люблю я его), но это все для себя. А для заказчика: Эксель и желательно без макросов/VBA, без вариантов (хотя вру, есть один клиент, которому принципиально нужно в Таблицах Гугл, потому что они не пользуются продуктами Microsoft).
Согласен и несогласен. Слезть с Эксель очень сложно, но в какой-то момент выбора просто нет. Он наступает, когда количество пользователей или сложность модели превышает определенный порог. Есть несколько продуктов (Quantrix, Anaplan, ...) которые уже преуспели в этой области. Проблема только в том, что они очень сложные и дорогие.
Коллега говорит вам о том, что у Excel много примеров использования, которая ваша программа не закрывает. Например, как универсальный инструмент обмена данными/моделями/отчетами и т.д. как внутри организации, так и за её пределами. А вы позиционируете его именно как замену Excel и прочих электронных таблиц.
Возможно вам стоит подумать над тем, чтобы продвигать продукт именно как инструмент расчетов/моделирования данных, который применим в таких-то ситуациях. И в этих ситуациях он круче Excel потому что А, Б, В.
Возможно вам стоит подумать над тем, чтобы продвигать продукт именно как инструмент расчетов/моделирования данных, который применим в таких-то ситуациях. И в этих ситуациях он круче Excel потому что А, Б, В.
Повторюсь, все зависит от ситуации. Если сидишь в фирме и пилишь отчеты для начальства, то да, можно использовать любые инструменты, которыми ты умеешь пользоваться и на которые дадут бюджет (потому что руководству все-равно нужно дать отчет и презенташку, а как ты их получил уже не важно). Но даже тут могут потребовать чтобы пользовался стандартом, потому что завтра ты уйдешь, а новый финансист или аналитик должен будет быстро войти в курс дел без необходимости изучать зоопарк экзотических программ.
Но если работаешь на заказ, то делаешь так, как хочет заказчик, без вариантов. И тут зависит от того, на каком рынке работаешь. На уровне «бизнес-план/финмодель инвестпроекта» я кроме Экселя и надстроек к нему ничего никогда в требованиях не видел. Наверняка в инвестбанках, хедж-фондах и прочих институтах с серьезной математикой и big-data ситуация другая, но абсолютно уверен, что у них тоже есть свои тулбоксы, который считаются отраслевым стандартом.
В общем, я двумя руками за новые удобные инструменты, но если этот инструмент не сможет сохранить итоговый файл в формате Эксель (в удобном и читабельном виде) чтобы я мог отправить его заказчику, то для меня лично он будет совершенно бесполезен. Увы :(.
Но если работаешь на заказ, то делаешь так, как хочет заказчик, без вариантов. И тут зависит от того, на каком рынке работаешь. На уровне «бизнес-план/финмодель инвестпроекта» я кроме Экселя и надстроек к нему ничего никогда в требованиях не видел. Наверняка в инвестбанках, хедж-фондах и прочих институтах с серьезной математикой и big-data ситуация другая, но абсолютно уверен, что у них тоже есть свои тулбоксы, который считаются отраслевым стандартом.
В общем, я двумя руками за новые удобные инструменты, но если этот инструмент не сможет сохранить итоговый файл в формате Эксель (в удобном и читабельном виде) чтобы я мог отправить его заказчику, то для меня лично он будет совершенно бесполезен. Увы :(.
Это интересная информация. Я в поисках более широкой аудитории. Этот экспорт в эксель должен содержать формулы? Ваши клиенты сами правят модель? Интересно как выглядят такие модели? Повторяющиеся скопированные листы для каждого продукта например?
Да, формулы должны быть обязательно. Когда модель уходит в банк или в госорган, там её будут проверять, в том числе смотреть правильно ли она отрабатывает при изменении показателей, поэтому все формулы должны работать. Ну и если мы говорим о серьезных проектах, то сами формулы тоже будут отсматривать (проверять не сжульничал ли я, скажем, жестко вбив «красивые» результаты в промежуточную ячейку).
Выглядят по-разному. Скажем, прямо сейчас делаю модель инвестпроекта под ГЧП по стандарту одного крупного банка. Там один продукт (точнее услуга), структура файла следующая:
1. Лист «Сценарии». В столбцах G и далее указываются параметры сценариев (наличие/отсутствие господдержки, использование/неиспользование лизинга, форма вклада инвестора в проект и т.д.), в столбце F формулы, которые подтягивают параметры из выбранного сценария (номер указывается в отдельной ячейке). Никаких вычислений на этом листе нет.
2. Лист «Исходные данные». Тут, соответственно, все вводные: капексы, опексы, календарные графики работ, суммы необходимых кредитов, вклада в акционерный капитал, лизинга и т.д. Ну и прогноз выручки. Все это завязано формулами на лист «Сценарии» и должно автоматически пересчитываться при изменении сценария. Все показатели развернуты поквартально на срок реализации проекта плюс 3 года. В общей сложности порядка 500 строк и 150 столбцов.
3. Лист «Расчеты». Основной лист, тут мы считаем детали. Графики начисления и выплаты процентов по кредитам, выплаты по договорам лизинга (все в вариантах диф. платежей и аннуитета, выбор идет в соответствии со сценарием), детальный расчет выручки, расчет налогов, показатели бюджетной и экономической эффективности и т.д. и т.п. Итого 950 строк на те же 150 столбцов.
4. Лист «Финансовая отчетность». Собираем прогнозную финансовую отчетность. Баланс, отчет о прибылях и убытках, отчет о движении денежных средств и т.д. Все так же в поквартальной разбивке на срок реализации проекта + 3 года. Размер 150 строк на 150 столбцов.
5. Последний лист «Контроль». Здесь выводим все контрольки: источники финансирования должны быть равны затратам, остатки денежных средств, посчитанные в отчете о движении денежных средств на листе «Финансовая отчетность» должны быть равны остаткам по каскаду на листе «Расчет», суммы процентов начисленных должны быть равны суммам процентов уплаченных и т.д. и т.п. Если все формулы сделаны правильно, то сходиться должно автоматически, но по факту сразу не сходится никогда, потому что всегда бывают косяки :). Самая маленькая таблица: 30 на 20.
В других случаях используются другие варианты. Скажем, для производственных проектов под бизнес-план как правило самая сложная часть это технологическая модель производства. Например, для рыбоводного предприятия это куча листов с движением стада помесячно, каждый лист — одна порода рыб, в разбивке по зарыблениям. Потом из этого делаем сводные показатели (масса рыб в УЗВ, общий расход кормов по видам корма, объем закупа малька, потребность в рыбоводах, потребность в медикаментах и т.д.) и уже от этих показателей считаем экономику.
А потом идем в банк и тамошний специалист начинает тыкать пальчиком и заявляет, что цены на продукцию завышены и их надо пересчитать, а еще надо посмотреть что будет при удорожании кормов, да и зарплаты у вас как-то низковаты, поднимите до двух минималок… и начинается самое веселье :).
Выглядят по-разному. Скажем, прямо сейчас делаю модель инвестпроекта под ГЧП по стандарту одного крупного банка. Там один продукт (точнее услуга), структура файла следующая:
1. Лист «Сценарии». В столбцах G и далее указываются параметры сценариев (наличие/отсутствие господдержки, использование/неиспользование лизинга, форма вклада инвестора в проект и т.д.), в столбце F формулы, которые подтягивают параметры из выбранного сценария (номер указывается в отдельной ячейке). Никаких вычислений на этом листе нет.
2. Лист «Исходные данные». Тут, соответственно, все вводные: капексы, опексы, календарные графики работ, суммы необходимых кредитов, вклада в акционерный капитал, лизинга и т.д. Ну и прогноз выручки. Все это завязано формулами на лист «Сценарии» и должно автоматически пересчитываться при изменении сценария. Все показатели развернуты поквартально на срок реализации проекта плюс 3 года. В общей сложности порядка 500 строк и 150 столбцов.
3. Лист «Расчеты». Основной лист, тут мы считаем детали. Графики начисления и выплаты процентов по кредитам, выплаты по договорам лизинга (все в вариантах диф. платежей и аннуитета, выбор идет в соответствии со сценарием), детальный расчет выручки, расчет налогов, показатели бюджетной и экономической эффективности и т.д. и т.п. Итого 950 строк на те же 150 столбцов.
4. Лист «Финансовая отчетность». Собираем прогнозную финансовую отчетность. Баланс, отчет о прибылях и убытках, отчет о движении денежных средств и т.д. Все так же в поквартальной разбивке на срок реализации проекта + 3 года. Размер 150 строк на 150 столбцов.
5. Последний лист «Контроль». Здесь выводим все контрольки: источники финансирования должны быть равны затратам, остатки денежных средств, посчитанные в отчете о движении денежных средств на листе «Финансовая отчетность» должны быть равны остаткам по каскаду на листе «Расчет», суммы процентов начисленных должны быть равны суммам процентов уплаченных и т.д. и т.п. Если все формулы сделаны правильно, то сходиться должно автоматически, но по факту сразу не сходится никогда, потому что всегда бывают косяки :). Самая маленькая таблица: 30 на 20.
В других случаях используются другие варианты. Скажем, для производственных проектов под бизнес-план как правило самая сложная часть это технологическая модель производства. Например, для рыбоводного предприятия это куча листов с движением стада помесячно, каждый лист — одна порода рыб, в разбивке по зарыблениям. Потом из этого делаем сводные показатели (масса рыб в УЗВ, общий расход кормов по видам корма, объем закупа малька, потребность в рыбоводах, потребность в медикаментах и т.д.) и уже от этих показателей считаем экономику.
А потом идем в банк и тамошний специалист начинает тыкать пальчиком и заявляет, что цены на продукцию завышены и их надо пересчитать, а еще надо посмотреть что будет при удорожании кормов, да и зарплаты у вас как-то низковаты, поднимите до двух минималок… и начинается самое веселье :).
Уважаемый автор, спасибо за статью!
Что-то интересное и перспективно-масштабное в Вашем подходе есть.
Несколько соображений и вопросов:
Что-то интересное и перспективно-масштабное в Вашем подходе есть.
Несколько соображений и вопросов:
1) По цитате ... На практике я встречал очень сложные системы, реализованные в Excel
кратко поделюсь — в этом году я (… как грамотный Excelист...?) бы привлечен в проект очистки и предподготовки данных для расчета производственно-финансовой модели — после сбора из разнородных источников, загрузки в промежуточный файл Excel, доочистки (вот до завершения этого этапа меня и коллег Заказчик подпустил)..., данные из листов этой файла загружаются в «священный» файл производственно-финансовой модели, стартует пересчет ее параметров, который занимает от 4 до 12 часов на весьма приличной рабочей станции, и о частом пересчёте (различных сценариев и т.п.) речь не идёт. Заказчик категорически не подпускает внешних исполнителей к самой модели, поэтому наши подозрения, что мы сможем что-то улучшить, пока остаются беспочвенными. Возможно, Ваши идеи позволят делать такие модели более быстрыми.
2) По подразделу Интерактивность ячеек
Правильно ли я понимаю, что расчетная формула, находящаяся в ячейке, возможно, состоящая из нескольких встроенных функций, может не только возвращать итоговое значение, но еще и влиять на оформление этой ячейки? Могут ли так же делать сами встроенные функции? — Например, функция =СреднееЗначение()… вызванная с конкретным (или интервал) значением «цветового» параметра, «возвращает» ячейке жёлтую заливку? Если да, то как быть в формулах, состоящих из нескольких (вложенных) встроенных функций — если пользователь задал разные конфликтующие значения цветовых параметров?
В целом не опасаетесь ли «каскадных побочных эффектов» из-за того, что множество формул и функций, будут иметь возможность возвращать не только значения, но и что-то еще?
Абзац «Кнопки в ячейках позволяют ....» стимулирует множество вопросов… про связь между кнопкой (ну или расширенно — элементом управления) с ячейкой — это не близкий ли аналог ActiveX-компонентов (флажки, списки....) вытащенных на рабочий лист Excel и связанных с зависимой (взаимо-влияющей) ячейкой (типично для флажков) и «наполняющими» ячейками (откуда берутся значения — типично для списков? Это кстати и про доступ пользователя к кнопке без доступа к ячейке — это аналог защищенного рабочего листа с разлоченными Active-X и защищенными ячейками?
Насчет кнопки, нажатие на которую приводит к копированию данных между листами — параметры процесса копирования — какой исходный диапазон (столбцы, строки, сплошной/несплошной, с возможной фильтрацией....) и куда нужно вставить («верхняя левая» ячейка) на листе-получателе — это все будет описываться свойствами чудо-кнопки? Я просто не могу представить, как это можно сделать иным способом — я знаю 2 — либо пользователь, либо параметризуемый макрос.
В целом не опасаетесь ли «каскадных побочных эффектов» из-за того, что множество формул и функций, будут иметь возможность возвращать не только значения, но и что-то еще?
Абзац «Кнопки в ячейках позволяют ....» стимулирует множество вопросов… про связь между кнопкой (ну или расширенно — элементом управления) с ячейкой — это не близкий ли аналог ActiveX-компонентов (флажки, списки....) вытащенных на рабочий лист Excel и связанных с зависимой (взаимо-влияющей) ячейкой (типично для флажков) и «наполняющими» ячейками (откуда берутся значения — типично для списков? Это кстати и про доступ пользователя к кнопке без доступа к ячейке — это аналог защищенного рабочего листа с разлоченными Active-X и защищенными ячейками?
Насчет кнопки, нажатие на которую приводит к копированию данных между листами — параметры процесса копирования — какой исходный диапазон (столбцы, строки, сплошной/несплошной, с возможной фильтрацией....) и куда нужно вставить («верхняя левая» ячейка) на листе-получателе — это все будет описываться свойствами чудо-кнопки? Я просто не могу представить, как это можно сделать иным способом — я знаю 2 — либо пользователь, либо параметризуемый макрос.
3) Кстати насчет макросов
Планируете ли встраивать в разрабатываемый продукт встроенный язык программирования? Если будет, то умоляю чтобы он был строжайше статически типизированным — как VBA в Excel — можно даже пожестче — вообще не подразумевать, что программные компоненты могут быть без директивы Option Explicit, и пожестче с приведением типов (но тут неоднозначно). Это я к тому, что если бы в Excel был какой-нибудь скриптовый не типизированный язык, то я бы сейчас выглядел на несколько лет старше (работаю с Excel-VBA 20 лет), и к тому, что мне периодически попадают на рефакторинг сложные (тысячи строк) многомодульные макросы, наполовину написанные мышью (макрорекордером), и без нормальной типизации — это, конечно, приносит денюжку, но это же мука…
4) Про грани куба, которые подписаны заголовками бизнес-объектов
Переименование заголовка приводит к пересчету формул модели (заполненной данными)? Переименование может потребоваться из-за уточнения смысла бизнес-объекта или из-за банального исправления ошибок. Это я так же к тому, что, к примеру, в VLOOKUP если номер столбца (из которого подбирается значений) вычисляется встроенной функцией, например, по заголовкам, то исправление в наименовании заголовка может привести к бессмысленному пересчету, а может и не привести — если правильно задать формулы, что вычисляемый номер столбца не пересчитывался — тогда и значения переизвлекать не нужно.
5) Про VLOOKUP
Складывается впечатление, что Вы несколько педалируете известные недостатки VLOOKUP (спекулируете на них?). Что вы скажете о полностью замещающей конструкции типа =ИНДЕКС(диапазон1; ПОИСКПОЗ(значение; диапазон2;0); СТОЛБЕЦ(диапазон3)) — доступна начиная с Excel 97, которая полностью исключает проблемы изменений взаимного расположения столбцов — источника ключевых значений, ключей из обрабатываемого списка, извлекаемых значений?
(ссылка на признанного мэтра www.planetaexcel.ru/techniques/2/92 );
ну и что скажете про свежайшее решение проблем VLOOKUPов и ИНДЕКС(ПОИСКПОЗ() — это новая суперфункция, которая (пока?) доступна только в обновляемом по подписке Excel 365 — ХLOOKUP (по русски это ПРОСМОТРикс, а не ПРОСМОТРхэ) — здесь внутри одной встроенной функции наряду с прочим решена и задача возвращения дефолтных значений, если найти значение не удалось.
ссылки по теме
www.planetaexcel.ru/techniques/25/10910
msoffice-prowork.com/ref/excel/excelfunc/lookup-reference/xlookup
support.office.com/ru-ru/article/функция-просмотрx-b7fd680e-6d10-43e6-84f9-88eae8bf5929
Складывается впечатление, что Вы несколько педалируете известные недостатки VLOOKUP (спекулируете на них?). Что вы скажете о полностью замещающей конструкции типа =ИНДЕКС(диапазон1; ПОИСКПОЗ(значение; диапазон2;0); СТОЛБЕЦ(диапазон3)) — доступна начиная с Excel 97, которая полностью исключает проблемы изменений взаимного расположения столбцов — источника ключевых значений, ключей из обрабатываемого списка, извлекаемых значений?
(ссылка на признанного мэтра www.planetaexcel.ru/techniques/2/92 );
ну и что скажете про свежайшее решение проблем VLOOKUPов и ИНДЕКС(ПОИСКПОЗ() — это новая суперфункция, которая (пока?) доступна только в обновляемом по подписке Excel 365 — ХLOOKUP (по русски это ПРОСМОТРикс, а не ПРОСМОТРхэ) — здесь внутри одной встроенной функции наряду с прочим решена и задача возвращения дефолтных значений, если найти значение не удалось.
ссылки по теме
www.planetaexcel.ru/techniques/25/10910
msoffice-prowork.com/ref/excel/excelfunc/lookup-reference/xlookup
support.office.com/ru-ru/article/функция-просмотрx-b7fd680e-6d10-43e6-84f9-88eae8bf5929
6) Пример с кодами валют и обменным курсом
иллюстрирует не недостатки традиционных табличных редакторов и потенциальные преимущества перспективных инструментов, а извечную программистскую проблему выбора «хранить или вычислять». Сделайте таблицу со столбцами Страна — КодСтраны — КодВалюты -ТекущийКурс и на один VLOOKUP станет меньше, ну и кстати хранить особо больше не придётся.
иллюстрирует не недостатки традиционных табличных редакторов и потенциальные преимущества перспективных инструментов, а извечную программистскую проблему выбора «хранить или вычислять». Сделайте таблицу со столбцами Страна — КодСтраны — КодВалюты -ТекущийКурс и на один VLOOKUP станет меньше, ну и кстати хранить особо больше не придётся.
7) Кроме Вас
сколько еще коллег участвует в мозговых штурмах — проектирует структуру продукта, базовые принципы, какие фичи сейчас какие на потом…? Ограниченным составом, и тем более в одиночку, сложно смотреть на продукт с разных сторон, выбирать баланс противоречивых требований и пожеланий.
сколько еще коллег участвует в мозговых штурмах — проектирует структуру продукта, базовые принципы, какие фичи сейчас какие на потом…? Ограниченным составом, и тем более в одиночку, сложно смотреть на продукт с разных сторон, выбирать баланс противоречивых требований и пожеланий.
Спасибо за очень развернутый комментарий.
На большую часть ваших вопросов есть ответы в документации. Сайт можно найти в Гугле, но я пошлю вам линк личным сообщением (если я правильно понял, публиковать линк я права не имею).
Насчет интерактивности и других функций: мне кажется самое простое, это запустить приложение и поиграться самому. Формулы значения и цвета не зависят друг от друга. Формула заливки, например, должна вернуть строку со спецификацией цвета (например "#FFFFFF"). Разные типы формул рассчитываются независимо друг от друга.
Насчет команды: разрабатываю пока я один. Но роль продукт менеджеров пока играют немногочисленные клиенты. Я стараюсь добавлять универсальные функции, которые решают не только конкретную проблему клиента, но и могут пригодиться в других моделях.
На большую часть ваших вопросов есть ответы в документации. Сайт можно найти в Гугле, но я пошлю вам линк личным сообщением (если я правильно понял, публиковать линк я права не имею).
Насчет интерактивности и других функций: мне кажется самое простое, это запустить приложение и поиграться самому. Формулы значения и цвета не зависят друг от друга. Формула заливки, например, должна вернуть строку со спецификацией цвета (например "#FFFFFF"). Разные типы формул рассчитываются независимо друг от друга.
Насчет команды: разрабатываю пока я один. Но роль продукт менеджеров пока играют немногочисленные клиенты. Я стараюсь добавлять универсальные функции, которые решают не только конкретную проблему клиента, но и могут пригодиться в других моделях.
В правилах сайта я ничего не нашел про запрет на ссылки в комментариях. Вот ссылка на проект, для тех кто не хочет гуглить: https://cubeweaver.com
Макросов пока нет (они еще никому не были нужны), но есть возможность создавать свои функции на C# или VB.NET.
читаю про очередной велосипед, и не понимаю конструкторов таких великов: ну решил автор убить тучу своих человеко- часов без проверки наличия альтернатив на рынке, а зачем? Начиная с Excel 2013 Microsoft уже такого в него повнедрял что вышеупомянутые офисные Access, VBA просто с этим меркнут (а предмет этой статьи просто закапывают в землю).
Пишу про киллер-связку: Power Query (продвинутый low code ETL с горой коннекторов к разным источникам данных и своим языком "M" для замороченных извращенцев которым мышки в нём почему-то не хватило) + Power Pivot с его колоночной аналитической СУБД (в его табулярных моделях кстати схемы "звезда/снежинка" категорически приветсвуются, как и в любых аналитических решениях) и его языком моделирования DAX (любой KPI показатель к вашим услугам). При этом бесшовная совместимость с Excel ибо его родные компоненты а понимание что можешь ворочать внутри оперативной памяти 120 миллионами записей в одной эксель книге — это приятно (хотя в таком случае Analysis Services конечно больше напрашивается)
Access и VBA конечно останутся как узкозаточенные инструменты, но в текущем мире они для решения Эксельных задач уже совершенно не актуальны. Пишу по 10 летнему опыту работы с Access, VBA (и в Эксель и в Access) и 6 летнему опыту работы с Power Query/Power Pivot/Power BI.
Автору конечно желаю коммерческого успеха с его продуктом и какого-либо интереса со стороны бизнеса (чтобы не было больно за потраченное время на разработку всего этого)
Спасибо за нежную заботу (в этот поздний час) о том, чтобы я с пользой проводил время. Насчет Power Query, M и DAX вы путаете теплое с мягким. Это инструменты для ETL и аналитики: подгрузить, подготовить и показать данные. CubeWeaver это система для финансового планирования и моделирования: ввод данных пользователем, вычисление и результата, агрегация, экспорт результата в Power BI или Tableau. Возможность поиграться с параметрами модели (симуляции).
заинтересовал продукт, цель -анализ и сопровождение инвестиционных проектов, которые веду в Экселе(гуглшите). но на мобильных устройствах продукт не стал работать, дескать, пикселей не хватает в экране :(
Вы пользуетесь Гугл-шитом на мобильном устройстве? Мне кажется это довольно не удобно? Вы просто заполняете там данные или формулы тоже пишите?
Да, пользуюсь. Телефон вообще основной инструмент, а гуглшит — для сопровождения бизнеса. Контролирую развитие и потоки денег в/из пары десятков инвестпроектов, каждый в гуглшите как лист представлен с одними примерно формулами, название листа — проект, плюс есть пивотлист с итогами. Так бы хорошо на ваш механизм проектировалось, но иметь только в компе без телефона — не комильфо. Плюс, на листах проекта ссылки на документы в гугл доках и договора в PDF на гугл диске.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
Электронные таблицы как средство разработки бизнес-приложений