Как стать автором
Обновить

Комментарии 70

Спасибо за вопрос. Сделал тестовый документ, в котором отладчик показал результат 0.30000000000000004, т.к. расчетчик реализован на JavaScript. Будет исправлено.
А как вы это исправлять будете, если в JS все числа это float? Создавать кастомный тип Decimal?
примерно как здесь: habr.com/post/159313
раздел «Работа с дробными числами»
Эта ошибка проявляется практически во всех языках.
JS, C, C++, Perl — это до чего прям щас руки дотянулись…
Интересно было бы узнать как они это будут побеждать.
По слухам, в последней версии Node.js это вроде поправлено. Но нужно проверять.
Нет. Не исправлено даже в самой последней на данный момент версии (v10.12.0)
в Perl 6 ошибки нет, т.к. там есть рациональные числа
$  perl6 -e 'say 0.1 + 0.2 == 0.3'
True

Не совсем, там все очень сложно, пока числа целые, они могут достигать 2 в 53й степени, при этом работать с ними будет сложно, битовые операции поддерживаются только до 2 в 32й. Поэтому да, для денег лучше использовать одну из реализаций BigDecimal.

Проблема решена — значения переводятся в tofixed со степенью 11 в соответствии с форматом хранения в postgresql
Она браузерная? Только браузерная?
Пока только в браузере. Но почти во всех и на всех платформах.
В 1С давным давно есть готовые и относительно неплохо работающие модули по бюджетированию и планированию.
Ниша 1С — мелкие и средние компании. В этой ниже бюджетирование проще и дешевле реализовывать на Excel и типовых решениях по бюджетированию. JetCalc ориентирован на крупные и очень крупные компании, для которых достаточно высокий порог вхождения на понимание системы в последующем окупается большой гибкостью и производительностью при работе с аналитической информацией.
Без предметного обоснования того какие недостатки 1С или конретных подсистем бюджетирования и планирования
а) Мешают ей/им быть использованными на т.н. «крупных предприятиях»
б) Не позволяют ей/им быть гибко настраиваемыми
в) Делают неконкурентноспособной производительность

ваше утверждение останется голословным.
Вопрос не в достоинствах или недостатках, а сравнительных затратах (денежных, временных, интеллектуальных) по внедрению конкретного решения. Чем крупнее компания, тем больше в ней различных «частных» случаев (а по большому счету бардака), унификация которых имеет не техническое, а политическое решение. Из своего опыта могу сказать, что лично видел достаточно крупную компанию, в которой планирование и учет были реализованы на 1С. Но для него характерно достаточно технологически однородное производство и очень высокий уровень порядка в учете, что встречается достаточно редко. В свою очередь прототип JetCalc изначально был ориентирован на работу в условиях бардака с постепенным наведением порядка в учете (справочники, методики, учетные политики, встречные сверки и т.п).
Ха-ха-ха-ха… Это типа вы так толсто-толсто оборвали себя некомпетентным маркетологом, не знающим программный продукт?
Их никто не использует. Вообще. По причинам, которые человек вот тут в статье указал.
В это ситеме бюджетирования, чтобы посто сказать, что «продажи=количество*цена» надо завести/изменить/проследить_версионность от 3 до 8 документов?
И это простейший пример. Про отлавливание минусов в складах, рабочем времени, убытках молчу — там таких философских категорий нет.
В статье сам процесс планирования описан крайне поверхностно, раскрыто не более 5% процесса, и то уже альтернтивы Экселю нет.
А вы про 1С. Хоть документацию по ней прочитайте, поробуйте больше двух связанных документов планировани внести — вы эту затею на 10-м матюке бросите.
И намне советуйте.
Я внедрял 1С много лет в том числе и систему бюджетирования, которая в изначальном сыром виде возможно и не является 100% юзер френдли, но представляет собой вполне сносный каркас, который при небольшом допиливании под конкретную ситуацию становится в т.ч. и юзер френдли. Чтобы заполнить данные по продажам на основе показателей предыдущих периодов, достаточно указать в настройках либо регистр продаж, либо счета бухгалтерского учета, на которых данные по продажам аккумулируются и нажать кнопку Заполнить. Половина из того, что написали вы мне не очень понятна. Я не понимаю зачем отслеживать версионность объектов для бюджетирования. На мой взгляд эта фраза лишена всякого смысла.

В чем преимущество вашего решения по сравнению с R или Jupiter Notebook?

R и Jupiter Notebook — системы обработки и визуализации имеющихся данных, JetCalc — система создания этих самых данных. Например, с помощью R можно рассчитать отклонение удельной себестоимости различных видов продукции от среднего уровня, с помощью Jupiter Notebook вывести полученные отклонения на график, JetCalc же позволят рассчитать эту самую удельную себестоимость на основе исходных данных об объемах производства, удельных норм, цен на материальные ресурсы, численности и средней заработной платы, налоговых ставок, балансовой стоимости основных средств и норм амортизации и т.п. При этом ничто не мешает в будущем подключить в качестве расширений к JetCalc модули, использующие функционал на R и Jupiter Notebook, если в этом возникнет нужда, либо реализовать механизм экспорта данных в определенном формате.
Подробнее о применении JetCalc при разработки модели расчета себестоимости продукции можно почитать по адресу www.leossnet.ru/?page_id=370
Выглядит ооочень интересно. Но возникает сразу несколько вопросов, которые из документации и материалов сайта не очевидны.

У меня управленческий учет организован в соответствии с принципами теории ограничений Голдратта, и например разброса операционных затрат на «себестоимость» мне нужно избежать, но калькуляция прямых затрат по продуктам необходима. Система позволит настроить полностью собственную модель расчета показателей, в том числе выработки (валовая выручка минус прямые затраты на единицу продаж) и чистой прибыли (упрощенно — выработка минус операционные затраты)?

Правильно ли я понял, что я могу вести учет в разных валютах как минимум на уровне отдельных компаний холдинга, а то и на уровне одного документа?

В документации отсутствует раздел про импорт данных, а это критический момент :) Смогу ли я настроить интеграцию с моей самописной системой в реальном времени?

Нет ли часом сборки под Докер? Это не проблема, но если вдруг есть — избавит от занудной возни…
По поводу моделей могу сказать, что пока не вижу никаких ограничений, чтобы реализовать любую модель управленческого учета любой степени сложности. Но даже если возникнут ограничения, то их легко можно будет устранить — код ведь под контролем.

Учет первичных данных можно вести в любых валютах, но при условии, что одно предприятие ведется в одной валюте. Отчетных же валют может быть три — по умолчанию (для России это рубли), а также две других произвольных (например, доллары и евро), ну и плюс для каждого предприятия в формах ввода своя собственная валюта (если она отличается от трех отчетных валют).

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

У прототипа JetCalc реализован механизм импорта через прикрепляемые к документу файлы в формате Excel, в которых в первых колонках и строках прописаны коды, по которым нужно импортировать данные. В существующей системе этот механизм не реализован лишь исходя из соображения его низкой приоритетности по сравнению с другими задачами. При необходимости эта задача может быть решена максимум за месяц, причем как посредством файлов, так и непосредственным подключением к внешним источникам данных. Основная проблема будет только в маппинге кодов JetCalc и внешних систем.

Причина низкого приоритета задачи по импорту данных обусловлена личным опытом, который утверждает, что проблема импорта данных на 90% зависит от порядка в первичном учете и на 10% от программных механизмов закачки данных. В своей же практике пока что не встречал разнородное предприятие с высоким уровнем стандартизации и унификации учетных данных и процедур.

Про докер (и все что угодно еще) могу сказать, как только появится реальный заказчик, которому это нужно, так будет реализован нужный функционал. Ну или возможен вариант с Вашим подключением к разработке.
Можно про импорт чуть подробнее? Поток данных в реальном времени у меня есть, но это просто данные о продажах и расходах в некоторой их части. Не хотелось бы вводить ручками то, что уже есть в том же постгресе. И заливать файлы импорта вручную тоже не хотелось бы, ибо будут данные запаздывать, а это иногда критично. Понятно, что можно хоть на уровне базы обеспечить обмен, но если понимать какой есть план по реализации импорта или какого-то API, было бы проще принимать решение.

Про Докер ясно, чтобы попробовать — все равно придется образ делать, так что подключусь к разработке воленс-ноленс :)
Так сейчас происходит закачка данных по продажам в прототипе:
1. В специальной админке маппается справочник предприятий с внешним справочником. Обычно это маппинг один к одному.
2. Далее маппается справочники продукции. Здесь несколько сложнее. В аналитической системе обычно продукция вводится без учета мелких классификаторов, а в учетной системе продукция учитывается с учетом самых мелких спецификаций. Поэтому мапиинг выполняется по схеме один ко многим.
3. Вручную прописывается маппинг колонок на стороне учетной системы.
4. Далее следует развилка. Можно выгружать первичку как есть с последующей группировкой в аналитической системе, либо наоборот, выружать в учетную систему таблицу маппингов, а затем получать уже готовые агрегированные данные с кодами аналитической системы.
5. Данные выгружаются в файл XML или JSON (кто как привык) и складываются в определенную расшаренную папку или настраивается веб-сервис с доступом к выгруженному файлу. Выгрузка в файл необходима, т.к. отчет в учетной системе формируется несколько часов (что поделать — SAP), а процедура импорта — в течение нескольких минут или даже секунд.
6. В отрытой форме ввода по продажам прикрепляется файл (или подключается к сервису доступа), а затем нажимается кнопка импорта, которая по своей сути выполняет эмуляцию ручного ввода, только данные в первичные ячейки заносятся не руками, а машиной из прикрепленного файла (сервиса).
6. Кнопка импорта может быть настроена как на заполнение доступных для ввода ячеек без сохранения, так и с одновременным сохранением в базу данных (дело вкуса).
7. Можно конечно обойтись без кнопки импорта, но тогда теряется контроль над вводом данных, особенно когда находятся ошибки в исходных данных и нужно выполнить повторный импорт. А для варианта импорта без сохранения можно увидеть, какие значения остались неизменными, а какие изменились. Причем история ячеек позволяет посмотреть как ранее введенное значение, так и видимое на экране еще не сохраненное значение.
8. Что касается «запаздывания данных», то хоть убейте, не могу представить себе ситуацию, когда все найденные экономистами косяки исправляются бухгалтерами точно в срок. Обычно после импорта данных «вылезают» контрольные точки с красными значениями, на выявление причин которых требуется время, на порядки превышающее время самой процедуры импорта.
По п. 8 — нет никаких SAP и бухгалтеров. Небольшие компании, типа ИП на УСН, все оперативно и прозрачно. Нужно чтобы все работало с минимумом человеческого фактора. Людям есть чем по делу заняться, и все что можно получить автоматически — надо получать автоматически и без лишних проверок.
Но для начала если при нажатии на кнопку импорта можно будет обратится к моей системе и получить от нее файл импорта (с этим проблем никаких) — то это вполне решение. Ну если я правильно понял, что так можно.
Ситуация понятна. Пока поставил в трекер задачу leossnet.myjetbrains.com/youtrack/issue/JC-454.
Сейчас на повестке поиск достаточно крупного (скорее организационно сложного) заказчика для первого внедрения JetCalc, сверхзадачей которого является доработка кода и формирование сообщества разработчиков и пользователей JetCalc. Как только станут ясны контуры такого сообщества, а код избавится от явных багов, можно будет вернуться к задаче импорта данных. Если же кто из сообщества возьмет на себя такую работу, то эта задача может быть решена быстрее.
Смысл курса валюты именно в том и есть, что он не постоянный, а меняется. И динамика курса по месяцма закладывается кк один из фундаментов бюджета.
Т.е. ваше програмулина ни на что не годная?
Для каждого отчетного периода в JetCalc устанавливается собственный курс валюты. Для фактических периодов он всегда отличается от периода к периоду, для планов же определение курса целиком зависит от применяемой к компании методики планирования. Из своего опыта могу сказать, что использование постоянного планового курса гораздо удобнее в плане последующего факторного анализа, чем применение плавающего планового курса, при условии, что годовые колебания курса укладываются в 10-20%. Особенно, если учесть, что установление планового курса — это не планирование, а прогнозирование, т.е. гадание на кофейной гуще. К тому же, устанавливая единый плановый курс для всех периодов, можно регулировать напряженность планов — для экспортирующих компаний плановый курс немного занижать относительно прогнозируемого, а для импортирующих или инвестирующих компаний — немного завышать и т.п.

Насчет годности не могу с Вами согласится. Кому-нибудь для чего-нибудь система да сгодится.
Добрый день! Очень интересная концепция. Возникла пара вопросов:
1. Как выполняется локализация UI?
2. Можно ли справочники замапить из своей системы?
3. White-labeling/или включение как чать своей системы трудно реализовать?
1. Каждый элемент интерфейса имеет свою метку, к которым затем происходит привязка наименований. Сейчас есть пока только русская локализация, и она устанавливается вручную. Но потом можно вынести на интерфейс переключение между множественными локализациями. Содержимое файла можно посмотреть здесь:
github.com/leossnet/jetcalc/blob/master/install/translate.json
Этот файл при установке копируется в папку /htdocs/jetcalc/static/custom/. Кроме того, этот файл можно редактировать с интерфейса пользователями с соответствующими правами.

2. По справочникам, и вообще по интеграции, изначально принято решение, что в ядро системы входят только универсальные решения, а специфические решение оформляются в виде внешних модулей и разрабатываются сторонними разработчиками. Для взаимодействия этих модулей предполагается разработка API, которого на сегодня нет, т.к. до конца не доработан код ядра, чтобы потом ничего не переделывать. Более того, есть ощущение, что если система пойдет в массы, то часть ядра придется перерабатывать.

3. Условия распространение ядра системы максимально свободные, поэтому нет никаких ограничений на использование JetCalc как часть других систем. С технической точки зрения в ядро системы будут входить только те решения, которые окажутся универсальными для всех. Поэтому если эта тема окажется интересной хотя бы двум независимым заказчикам, то можно будет подумать о разработке специфического API.
Спасибо за подробный ответ!
Было бы здорово если бы систему можно было использовать сразу на нескольких языках.
И вот что было бы совсем замечательно — это возможность «публиковать»/включать/имбеддить отчеты/графики/презентации. Без регистрации и СМС :)… Тогда можно было бы вместо apache zeppelin использовать
Про многоязычный интерфейс дело решенное, вопрос только во времени.
По презентациям немного расскажу здесь, т.к. эта тема еще не доделана (есть только макет презентации и работающий механизм хранимых отчетов):
1. Каждый документ имеет базовое табличное представление.
2. Опционально документ может быть представлен в графическом (уже есть) или текстовом (пока нет) виде.
3. Каждое представление может быть настроено путем фильтрации строк и колонок, которое сохраняется в виде хранимого отчета со своим кодом и наименованием.
4. В рамках презентации могут быть объединены один или несколько ранее настроенных хранимых отчетов из разных документов.
5. При изменении настроек хранимого отчета в рамках документа автоматически изменяются все ссылки на эти хранимые отчеты в различных презентациях.
6. Для построения графиков используется бесплатная библиотека C3, хотя может быть подключена любая другая библиотека (пока в планах).
7. Текстовое представление представляет собой текстовый шаблон, в котором большая часть документа генерируется автоматически путем построения фраз, состоящих из наименований показателей и их значений, представленных в табличной части, объединенных типовыми связками. В прототипе JetCalc этот механизм реализован, но в новой системе он требует переосмысления, поэтому будет реализован не ранее чем через 2-3 года.
Добрый день! Спасибо за вашу работу.
Установил Jetcalc к себе на ubuntu 16.04 при вводе логина admin пароль admin пишет Пользователь не найден.
В чем может быть проблемма, где хранятся пользователи?
Почему в демо версии на вашем сайте очень тормозит система?
Объемы производства за Январь 2018 — Отчет.
По пользователю admin — это ошибка установки. См. задачу: leossnet.myjetbrains.com/youtrack/issue/JC-449.
Просто Вы первый, кто реально развернул у себя систему. Постараемся быстро исправить, о чем можно узнать из трекера.

На тему тормозов прошу уточнить, в чем это выражается. Нормальным считается обновление содержимого документа за 1-3 секунды. По объемам производства — это менее 1 секунды. Возможно проблема в скорости сети или проверке антивирусом скриптов веб-клиента.
На тему тормозов прошу уточнить, в чем это выражается.

Это я ошибся, просто зашел на демку по адресу dev.jetcalc.com, вот там все тормозит.
А тут jetcalc.leossnet.ru работает.
Подскажите а где можно задавать вопросы по вашей программе, что бы хабр незахломлять.
Тоже развернул сегодня и не смог залогиниться
Сходил по ссылке там пишут что ошибку установки нашли уже 3 месяца назад
То есть систему не устанавливали еще ни разу?
Ошибку с установкой поправили. Протестировано на виртуалке Ubuntu 16.04.
После входа в систему нужно в разделе Модули-Настройки ввести свой логи GitHub и пароль. Это позволит установить модели и модули на соответствующих вкладках.
Рекомендуется для начала установить модель «Финансы». Чтобы модель стала доступна пользователям, нужно добавить хотя бы один объект учета (предприятие).
В некоторых случаях нужно выйти из системы и снова войти, чтобы пользователи увидели изменения.
В целом же по всем ошибкам и предложениям прошу писать на почту jetcalc@leossnet.ru или в группу www.facebook.com/groups/jetcalc — буду сразу писать в документацию на GitBook.
Прям бальзам на душу: 2002 год, а я в банке ваяю подобную аналитическую систему… :) Но все же отличную от описаной.
Честно говоря сразу возник вопрос: а почему изменение модели это проблема? Любая аналитическая система как раз строится на принципах, позволяющих быстро измененять модели данных. Excel или другой табличный процессор для этого не предназначен. Другое дело, что он знаком всем своим интерфейсом.
Простите, а можно полюбопытствовать, зачем именно банку нужная подобная система? Насколько я понимаю, для контроля инвестиционных проектов. И в этом вопрос: насколько глубоко банку интересно этот процесс контролировать? Достаточно ли общих инвестиционных показателей или хотелось бы видеть подробности производственных процессов (предположим, этот было бы просто сделать)?
Банк -урезанное производство. И все, что пресуще производству, все находит оражение и в банке. Конечно не в том, может, объеме, и не с теми сущьностями, но от перестановки мест слагаемых, как говорится…
Прогнозирование и конроль в банке бывает даже жестче. Например, прогноз наличия средств для покупки валюты или игры на бирже нужен в реалтайме с учетом недопулученной прибыли, денег в пути, выплат клиентов и т.п.
На производстве же не настолько быстро обычно, хотя бывали случаи в 90-00х, когда инфляция была дикая и нужно было оООчень быстро реагировать, но объемы, с учетом позиций, могут быть огромные (метизы, например) — та же big data. И тут с Excel'ом или JavaScript делать нечего — вылетаем по памяти :). Нужно работать со столбцами (измерениями) и потоками.
Проблема не в изменении модели, а в скорости такого изменения. Если руководителю нужна информация завтра, а модель может быть изменена послезавтра, то такое изменение никому не нужно — решение будет принято на основе старой модели с некоторыми поправками в голове руководителя.
Так вот если строятся модели на основе не таблиц, а измерений (столбцов, кубов и т.п.), то изменение ничего не стоит — меняешь, а точнее строишь модель на лету. Т.к. одному нужно в одном разрезе, другому в другом, одному консолидировано, а другому в деталях. В аналитике не работают с косными структурами
JetCalc осознанно ушел от модели данных на основе кубов, которая не позволяет выполнять разные хитрые расчеты, например калькуляции основного производства на основе рекурсивно рассчитываемого баланса металлов. Более того, возможность манипулирования кубами нужна очень узкой категории специалистов-аналитиков. Подавляющему же большинству руководителей нужна информация в жестко заданном формате, чтобы каждый раз не тратить время на изучение структуры документа, а можно было лишь взглянуть на документ за очередной отчетный период, чтобы понять текущую ситуацию.

Поэтому JetCalc позиционируется как кибернетическая система управления экономикой сложных хозяйствующих субъектов с элементами контроля исполнительской дисциплины. Аналогом JetCalc в технических системах является киповское оборудование, для которого устанавливаются допустимые диапазоны значений, получаемые с датчиков оборудования, чтобы производить периодический мониторинг работающего оборудования и выдавать сигнал только в случае выхода показаний за допустимые пределы.
Вот именно в формате, а вы пытаетесь совместить модельи формат. Никто не говорит, что руководителю нужно каждый раз изобретать модель. Но предоставить возможность работы с сущностями, а все аггрегаторы и калькуляторы для него не должны бытьвидны
Проблема в том, что руководителю всегда нужна информация еще вчера. А крайним, если вдруг окажется ошибка в расчетах, всегда выступает экономист. Поэтому для быстрого реагирования на запросы руководителей и нужна система, позволяющая экономисту быстро учесть новые вводные, чтобы выполнить самые сложные расчеты.

Конечно, можно посчитать и на коленке, но тогда нет никаких гарантий, что до исполнителей в других подразделениях дойдет именно та информация, которая должна дойти по расчетам экономиста.
Вы рассматриваете подход, когда документы отчетности живут отдельно от основных данных? У руководителя должен быть АРМ с готовыми отчетами-представлениями всех данных в нужных разрезах. Просить каждый раз экономиста сделать отчет и каждый раз зависить от настроения и точности исполнителя — это даже не анахронизм, извините.
Работая что на производстве, в торговле, что в банке первым делом, при внедрении нового автоматизированного комплекса грамотный руководитель заказывает свои элементы управления. Пока пишется и отлаживается, да, может спрашивать подчиненных предоставлять эти данные. Например, в банке было чуть ли не ежечасно фин. директор прибегал с вопросом: сколько денег на корр. счете. А разработчики посчитали, что эти данные не критичны и не дали интрумент руководителю, чтобы он видел картину в динамике втечении дня, а не только как факт в конце после всех сделок. Поэтому быстро в обход основного ПО пришлось делать все нужные срезы и выжимки, а также получение и агрегацию данных для них, чтобы можно было делать прогноз хотя бы с отставанием до 5 минут.
(было физическое ограничение репликации базы данных). Иногда и в стратегии играют роль секунды, а не только в тактике. Например, идут переговоры с крупным клиентом о предоставлении большого кредита. Да, подготавливается пакетдокументов с анализом. Но клиент хочет больше сумму. Т.к. клиент большой отказ может негативно сыграть всем. Банк рискует исходя из оперативной картины, например, заходя деньги другого клиента и можно на них рассчитывать. И не кто не побежит даже к главбуху за этими данными они должны быть перед глазами постоянно в акктуальном состоянии.
Уточню определения. JetCalc позиционируется как система управления экономикой, которая имеет временной лаг длиной в месяц, в течение которого происходит формирование оборотов и остатков по всем счетам в бухгалтерском учете. Причем за отчетный месяц такая работа завершается не ранее, чем через 2-3 недели по окончании этого месяца.

То, что Вы приводите в качестве примера, являются системами управления режима реального времени, типа клиент-банка и диспетчеризации производства. Кому нужно, и так получают доступ к таким системам, и для этого не требуется создание каких-либо дополнительных программных прокладок.

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

По этой причине для головной организации гораздо важнее, чем технологическая скорость получения информации, становится обеспечение синхронности получения данных от отдельных предприятий, сопоставимости однородных показателей по разным предприятиям, а также, самое главное, достоверности получаемой информации. А искажения информации могут возникать совершенно по разным причинам — неправильное отражение первичных документов, расхождения в учетных политиках контрагентов, несвоевременное предоставление первичных документов и т.п. В результате таких ошибок сводные результаты по компании могут стать совершенно не адекватными, следствием чего становятся неверные управленческие решение, ведущие в конечном счете к убыткам.
"… Для таких компаний самый обычный показатель, например, выручка от продаж, умножается на число предприятий компании, например на 100..."
Боюсь, вы рассматриваете частные примеры без должного опыта и хороших примеров управления именно крупных предприятий. Приводимые вами примеры и подходы присущи, как раз, мелким предприятиям с соответствующими, скажем так, «традициями», не имеющими ничего общего ни с экономикой ни с эффективным управлением.
И еще очень важно замечание. По моему глубокому убеждению, если руководитель любого уровня лично занимается анализом первичных данных, он является некомпетентным в своей сфере и занимает чужое место. Основные функции руководителя — организация и стратегия. И если он занимается первичным анализом, значит он не умеет делегировать полномочия, не доверяет подчиненным, не может четко сформулировать свою мысль и т.п.

Правильное поведение руководителя — найти подходящего специалиста, организовать внедрение JetCalc и создать систему регулярного управления на основе набора документов управленческой отчетности, отражающей все ключевые особенности бизнеса компании.
Из Начало работы в JetCalc. Глава 6. Расчетная система
1...., в системе JetCalc используются ячейки вида $f105215@On?, где $f105215 — код строки (строка 215 формы f105), @On — код колонки (остаток на начало),? — завершающий символ.

2. В системе JetCalc каждая ячейка имеет шесть измерений — строка, колонка, год, период, объект учета, валюта — поэтому полный синтаксис ссылки на ячейку, представленной в предыдущем пункте, будет выглядеть следующим образом: $f105215@On.Y2017.P11#210[RUB]?, где .Y2017 — 2017 год, .P11 — период 11 (январь), #210 — предприятие с кодом 210, RUB — код валюты рубль.

— ну, никак не альтернатива для простого экономиста, освоившего =СУММ(A1;A76). Как технологический конкурент для Oracle Hyperion Planning или решениям на 1С вполне допускаю.

Проблема не в изменении модели, а в скорости такого изменения. Если руководителю нужна информация завтра, а модель может быть изменена послезавтра, то такое изменение никому не нужно — решение будет принято на основе старой модели с некоторыми поправками в голове руководителя.

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

И решение этой проблеме давно уже придумали. В экономике закон сохранения стоимости такой же, как в физике закон сохранения энергии: если где-то что-то убавилось, значит куда-то в таком же объеме прибавилось. Правда экономисты от этого бухгалтерского закона, как от огня бегают, поэтому и системы бюджетирования высоко взлетев, часто больно падают.

Мой совет. Присмотритесь к планированию движения стоимости в виде двойной записи — как в бухгалтерии факт учитывается: Дебет-Кредит-Сумма. Чтоб в модели с самого начала баланс был заложен, когда расходы с доходами сходятся. Такого ваши конкуренты пока почему-то не предлагают.
Так вроде в JetCalc как раз двойная запись реализована?
Под моделью в JetCalc подразумевается набор связанных формулами документов, каждый из которых отражает аналитику определенного бухгалтерского счета (хотя реализация этого принципа целиком и полностью отдается на откуп профессионализма разработчика модели). Некоторые бухгалтерские счета содержат явно определенные коды бухгалтерских счетов (например, 90-продажи или 43-готовая продукция), некоторые неявно (например, 26-управленческие расходы), а некоторые являются комплексными документами, на которых отражаются остатки и обороты по счету в корреспонденции с другими счетами (например, 20-калькуляции основного производства).

Более того, концепция бухгалтерской проводки (двойной записи) в JetCalc расширена и названа бизнес-транзакция (коротко «бизтран»), которая позволяет оформлять одной проводкой операции между двумя юридическими лицами (например, д-т 10 к-т 90 — поступление продукции на склад предприятия А и продажа продукции с предприятия Б).

Концепция бизтрана позволяет на основе концепции двойной записи настраивать модели с формульными связями между множеством юридических лиц, объединенных в рамках холдинга, что обеспечивает возможность автоматической прокачки данных по приходу у одного юридического лица при вводе данных у другого юридического лица по связанным бизтран-операциям. И конечно же, при добавлении любой аналитики по какому-либо счету (продукция, контрагент, договор, статья договора) автоматически добавляются необходимые записи по всем связанным счетам как самого предприятия, так и его контрагента.

Данный функционал в JetCalc пока не доработан, т.к. не совсем понятен уровень его востребованности у потенциальных пользователей opensource-проекта. Хотя в прототипе JetCalc на основе этого функционала уже давно настроены аналитические документы по встречным сверкам покупок-продаж, дебиторской-кредиторской задолженности и выданных-полученных займов.
Что касается первой части Вашего вопроса, касающейся сложности формул вида $f105215@On.Y2017.P11#210[RUB]?, то данное представление является аналогом байт-кода, удобного для применения расчетной системой JetCalc. На практике формулы обычно представлены в виде @On? — @Ok? (расчет изменения остатков на уровне колонки) или $f120100? — @f120200? (расчет валовой прибыли на уровне строки). Недостающую часть формул расчетчик JetCalc преобразует в контексте документа при его первом открытии, когда становятся известны код объекта учета, код периода и код года, а также код валюты.

Более того, обычные формулы суммирования, которые на практике составляют 80-90% от общего числа формул бухгалтерского документа, вообще не нужно писать — достаточно поставить крыжики в нужных местах.

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

Что касается необходимого времени для настройки модели, то приведенный выше пример с настройкой системы калькулирования для черной металлургии занял примерно 3 недели, включая время на изучение методологии расчета. Нудное же заведение различных справочников и статей можно обойти путем простого копирования подготовленной в Excel структуры документа в новый документ JetCalc простым копипастом.

… глубокое знание экономистом специфики бизнеса своей компании и понимание логики бухгалтерского учета на уровне главной книги, позволяющей классифицировать любую хозяйственную операцию в виде бухгалтерской проводки. И именно на такого специалиста рассчитана система JetCalc.
Качество работы этих мифических специалистов меня очень сильно и беспокоит.

Более того, концепция бухгалтерской проводки (двойной записи) в JetCalc расширена и названа бизнес-транзакция (коротко «бизтран»)

Ткните меня, пожалуйста, где можно пощупать ваши «бизтран». В описании системы слишком кратко и операции между двумя юридическими лицами пока не интересуют.

Интересует система с возможностью формирования описанных вами отчетов из данных в виде двойной записи (проводок) с индивидуальными наборами аналитики по каждому счету. Я понимаю, что технически это реализуемо в JetCalc. Интересует, существуют ли инструменты удобной работы пользователя с двойной записью, когда проводок >1млн. большая часть будет загружаться из учетной системы, но пользователи должны иметь удобные инструменты корректировки и анализа данных, также важен контроль ввода аналитических признаков по 60 — Контрагенты, договоры, по 10 Номенклатура, по 20 — заказы и т.д…
Согласен, качество таких специалистов является критически важным фактором для успешности построения системы управления экономикой. Поэтому на своем сайте считаю необходимым выкладывать материалы методологического плана для этих самых экономистов, а также лично принимать участие в их подготовке.

Что касается бизтранов, то показать могу только при личной встрече, т.к. в демо-версии пока такой функционал не настроен. Либо можно подождать какое-то время для его появления в демо-версии или в документации (что появится раньше). А еще лучше подключайтесь к разработке, и тогда узнаете о еще более масштабных концепциях.
Как там исправление косяка с установкой?
Работа идет. Как только будет исправлено, сразу отпишусь здесь.
Ошибку с установкой поправили. Протестировано на виртуалке Ubuntu 16.04.
После входа в систему нужно в разделе Модули-Настройки ввести свой логи GitHub и пароль. Это позволит установить модели и модули на соответствующих вкладках.
Рекомендуется для начала установить модель «Финансы». Чтобы модель стала доступна пользователям, нужно добавить хотя бы один объект учета (предприятие).
В некоторых случаях нужно выйти из системы и снова войти, чтобы пользователи увидели изменения.
В целом же по всем ошибкам и предложениям прошу писать на почту jetcalc@leossnet.ru или в группу www.facebook.com/groups/jetcalc — буду сразу писать в документацию на GitBook.
На ubuntu 16.04 установка останавливается на проверке статуса mongodb
если строчку закомментить, то идет дальше
но в итоге что-то не запускается и окно с логином не выводит
С ошибкой встречались, но пока она воспроизводится не всегда и не на всех машинах. Тем не менее, будем пытаться отловить.
на 14,04 завелось
По адресу jetcalc.leossnet.ru/virtual/Ubuntu16_jetcalc.rar можно скачать настроенную демо-версию JetCalc в виде образа VirtualBox для локального тестирования с логином admin и паролем admin. Для удаленного входа через PuTTY на виртуальный локальный сервер localhost по порту 2222 необходимо использовать логин jetcalc и пароль jetcalc.
В JetCalc добавлена функция агрегирования данных по отдельным атрибутам объектов учета (дивизионы, отрасли, регионы, города, группы, типы объектов учета). Для расчета агрегата необходимо нажать на кнопку с символом суммы, расположенной слева от списка объектов учета. Повторный щелчок по кнопке суммы отключает агрегацию и возвращает данные предыдущего объекта учета.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации