All streams
Search
Write a publication
Pull to refresh
1
0
Сергей Сергеев @leossnet

Экономист

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

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

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

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

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

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

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

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

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

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

Данный функционал в JetCalc пока не доработан, т.к. не совсем понятен уровень его востребованности у потенциальных пользователей opensource-проекта. Хотя в прототипе JetCalc на основе этого функционала уже давно настроены аналитические документы по встречным сверкам покупок-продаж, дебиторской-кредиторской задолженности и выданных-полученных займов.
Проблема не в изменении модели, а в скорости такого изменения. Если руководителю нужна информация завтра, а модель может быть изменена послезавтра, то такое изменение никому не нужно — решение будет принято на основе старой модели с некоторыми поправками в голове руководителя.
По пользователю admin — это ошибка установки. См. задачу: leossnet.myjetbrains.com/youtrack/issue/JC-449.
Просто Вы первый, кто реально развернул у себя систему. Постараемся быстро исправить, о чем можно узнать из трекера.

На тему тормозов прошу уточнить, в чем это выражается. Нормальным считается обновление содержимого документа за 1-3 секунды. По объемам производства — это менее 1 секунды. Возможно проблема в скорости сети или проверке антивирусом скриптов веб-клиента.
Про многоязычный интерфейс дело решенное, вопрос только во времени.
По презентациям немного расскажу здесь, т.к. эта тема еще не доделана (есть только макет презентации и работающий механизм хранимых отчетов):
1. Каждый документ имеет базовое табличное представление.
2. Опционально документ может быть представлен в графическом (уже есть) или текстовом (пока нет) виде.
3. Каждое представление может быть настроено путем фильтрации строк и колонок, которое сохраняется в виде хранимого отчета со своим кодом и наименованием.
4. В рамках презентации могут быть объединены один или несколько ранее настроенных хранимых отчетов из разных документов.
5. При изменении настроек хранимого отчета в рамках документа автоматически изменяются все ссылки на эти хранимые отчеты в различных презентациях.
6. Для построения графиков используется бесплатная библиотека C3, хотя может быть подключена любая другая библиотека (пока в планах).
7. Текстовое представление представляет собой текстовый шаблон, в котором большая часть документа генерируется автоматически путем построения фраз, состоящих из наименований показателей и их значений, представленных в табличной части, объединенных типовыми связками. В прототипе JetCalc этот механизм реализован, но в новой системе он требует переосмысления, поэтому будет реализован не ранее чем через 2-3 года.
1. Каждый элемент интерфейса имеет свою метку, к которым затем происходит привязка наименований. Сейчас есть пока только русская локализация, и она устанавливается вручную. Но потом можно вынести на интерфейс переключение между множественными локализациями. Содержимое файла можно посмотреть здесь:
github.com/leossnet/jetcalc/blob/master/install/translate.json
Этот файл при установке копируется в папку /htdocs/jetcalc/static/custom/. Кроме того, этот файл можно редактировать с интерфейса пользователями с соответствующими правами.

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

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

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

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

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

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

Про докер (и все что угодно еще) могу сказать, как только появится реальный заказчик, которому это нужно, так будет реализован нужный функционал. Ну или возможен вариант с Вашим подключением к разработке.
Вопрос не в достоинствах или недостатках, а сравнительных затратах (денежных, временных, интеллектуальных) по внедрению конкретного решения. Чем крупнее компания, тем больше в ней различных «частных» случаев (а по большому счету бардака), унификация которых имеет не техническое, а политическое решение. Из своего опыта могу сказать, что лично видел достаточно крупную компанию, в которой планирование и учет были реализованы на 1С. Но для него характерно достаточно технологически однородное производство и очень высокий уровень порядка в учете, что встречается достаточно редко. В свою очередь прототип JetCalc изначально был ориентирован на работу в условиях бардака с постепенным наведением порядка в учете (справочники, методики, учетные политики, встречные сверки и т.п).
примерно как здесь: habr.com/post/159313
раздел «Работа с дробными числами»
Подробнее о применении JetCalc при разработки модели расчета себестоимости продукции можно почитать по адресу www.leossnet.ru/?page_id=370
R и Jupiter Notebook — системы обработки и визуализации имеющихся данных, JetCalc — система создания этих самых данных. Например, с помощью R можно рассчитать отклонение удельной себестоимости различных видов продукции от среднего уровня, с помощью Jupiter Notebook вывести полученные отклонения на график, JetCalc же позволят рассчитать эту самую удельную себестоимость на основе исходных данных об объемах производства, удельных норм, цен на материальные ресурсы, численности и средней заработной платы, налоговых ставок, балансовой стоимости основных средств и норм амортизации и т.п. При этом ничто не мешает в будущем подключить в качестве расширений к JetCalc модули, использующие функционал на R и Jupiter Notebook, если в этом возникнет нужда, либо реализовать механизм экспорта данных в определенном формате.
Спасибо за вопрос. Сделал тестовый документ, в котором отладчик показал результат 0.30000000000000004, т.к. расчетчик реализован на JavaScript. Будет исправлено.

Information

Rating
Does not participate
Location
Свердловская обл., Россия
Date of birth
Registered
Activity