Чем можно заменить связку MS Excel + VBA в Linux?

Question

[Денис _______________]

Я работаю в строительстве. В связи с последними веяниями, из-за которых наша страна решила переходить на отечественное ПО
publication.pravo.gov.ru/Document/View/0001202203300001
встал вопрос, как развивать свое приложение, работающее в рамках малой автоматизации рутин, которые облегчают заполнение шаблонных документов инженерам ПТО.

В рамках этой статьи я сравнивал работоспособность под Линукс некоторые базовые функции своего приложения, минимально-необходимый набор,
https://habr.com/ru/post/674580/
но столкнулся со следующими проблемами:
1. относительно низкая скорость на запись StarBasic в ячейку по сравнению с VBA даже работающем через Wine в Linux (порядка 30секунд против 6минут для поля 1000 х 1000 ячеек)
2. неполное соответствие формул и функционала Excel и Calc
3. LO и OO открытое ПО, но не входят в реестр российского ПО, однако многие российские дистрибутивы Linux поставляются именно с LO.

Соответственно я в поиске платформы для замены связки Excel + VBA, как самой распространенной, с одной стороны есть ли под Linux аналог Visual Studio? т.е. будет ли лучше, например, совсем отказаться от Basic'а и вынести макрос в отдельный модуль, или наоборот можно ли как то ускорить StarBasic в самом LO?

Comments

[Viktor T2]

Юзайте скриптики на пайтоне. Хех.
UPD
Pandas + XlsxWriter , например

[Василий Банников]

с одной стороны есть ли под Linux аналог Visual Studio?

Зависит от того, для каких задач. Есть разные среды от JetBrains, есть Eclipse, VS Code / VSCodium

[mayton2019]

1. относительно низкая скорость на запись StarBasic в ячейку по сравнению с VBA даже работающем через Wine в Linux (порядка 30секунд против 6минут для поля 1000 х 1000 ячеек)

Непонятно как делались сравнительные тесты. Excel + VBA против LibreOffice + Starbasic?
Здесь очень велик шанс что формат документа который использует LibreOffice просто неудачен
или неоптимизирован для частых Updates. Да и вообще вам сильно повезло что VBA так быстро работал.

Проблема эта скорее всего нерешаема. Что можно предложить. Вообще уйти от SpreadSheet как от носителя
информации. Особенно в тех кейсах как вы описали. Переходите в нормальные базы данных (Postgres) и уже
из них выгружайте SpreadSheet как отчет.

[Денис _______________]

mayton2019, таблицы это очень удобно с т.з. фронтенда, т.е. в них очень удобно вводить текстовую и цифровую информацию, а еще править ее. Я пытался запилить так что бы из нее данные выгружались и хранились в том же Access, но не смог реализовать двунаправленную связь... С другой стороны а зачем, если таблицы нормально так хранят информацию и без БД.

[CityCat4]

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

[Денис _______________]

CityCat4,
Кстати есть ли под Линукс бесплатные IDE аналоги VisualStudio ну там набросать на форму кнопки-списки-менюшки, что бы потом обвязать это кодом и через такое приложение уже что-то делать с таблицами через python или что-то в этом роде?

[Александр Нестеров]

Денис _______________,
VS code (общего назначения)
Если для питона, то PyCharm. Правда бесплатная вроде как заточена исключительно под него.

[Денис _______________]

Александр Нестеров,
Я не совсем корректно выразился, то что Вы перечислили это прекрасные IDE, в плане продвинуты текстовые редакторы с отладкой, но меня интересует создание автоматическое/ручное модулей окна, наподобие как это сделано в VBA/VB/VS, типа такого:

Просто я бегло погуглил и не нашел такого функционала в перечисленных Вами IDE

[Александр Нестеров]

Денис _______________, а, в этом плане.
PyQT5 + QT Designer.

[Денис _______________]

Александр Нестеров,
Спасибо, попробую

[CityCat4]

QT Designer, насколько я знаю. Хотя сам конечно не пробовал ни разу, все хочу постигнуть дзен гуевого программирования, но проклятый баш все не выпускает :)

[Adamos]

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

[Денис _______________]

Adamos, у меня нет желания каждому юзеру пихать Апач в нагрузку к паре файлов с таблицами, только лишь для того что бы у него на экране 15" рабочего ноутбука кнопочка была "правильных" размеров. Я думаю такое можно решить просто определив разрешение монитора, что бы выводить по условию свой вариант формы под каждое разрешение. Примерно так же это решается и для WEB-интерфейса, когда в зависимости от разрешения определяются размеры пропорций.

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

VBA, который по сути тот же QBasic 4.5, вообще технология конца 80-х в своей сути, однако решать современных задачи он способен до сих пор. Опять же поймите, я не являюсь профессиональным программистом, мне главное сделать удобно, так что бы работало, пусть не оптимально, но что бы было просто как автомат Калашникова и безотказно. Если мне будет проще писать в каком-нибудь TASM под условный DX486, то я буду в нем писать такой софт. Если я, в силу того что, по профессии сметчик-строитель, не способен освоить программирование баз данных и WEB-интерфейсов, то я не буду этого делать. У меня на неделе есть порядка 4-16часов что бы сделать что-то полезное для себя и поделиться этим с другими, поэтому мне нужен результат здесь и сразу. А новая технология или старая - монопенесуале, т.к. доход я получаю от другого рода деятельности. И я понимаю что профессиональному прогеру я не конкурент, как и то, что у меня нет денег его нанять. Такова жизнь.

[Adamos]

Денис _______________, я вам под другим ответом написал вариант, не требующий никаких Апачей. Но, увы, разбираться, и всерьез, этот вариант требует. Но я сам выкинул на помойку столько освоенного с тех самых 80-х просто потому, что оно клинически устарело, что считаю полезным предостеречь других от освоения того, что уже просится на свалку.

сметчик-строитель не способен освоить программирование баз данных и WEB-интерфейсов

Я четверть века назад закончил таки именно инженерно-строительный факультет ;)

[Денис _______________]

Но я сам выкинул на помойку столько освоенного с тех самых 80-х просто потому, что оно клинически устарело, что считаю полезным предостеречь других от освоения того, что уже просится на свалку.

Спасибо. Буду иметь ввиду.

Я четверть века назад закончил таки именно инженерно-строительный факультет ;)

Коллега :)

[Viktor T2]

Для формошлепства на пайтон Tkinter - самый простой и примитивный GUI на свете.
https://pythonru.com/uroki/obuchenie-python-gui-ur...
https://python-scripts.com/tkinter
Графического редактора нет.
Интерфейс описывается командами.
Осваивается за 2 дня.
P.S. Для табличных данных можно pandastable

[Максим Ярошевич]

Недавно был сильно удивлён, что макросы в Excel заработали в Linux в LibreOffice - может, ничего менять и не надо?
Советы Adamos - это как предложение Илона Маска вместо привычных дорог запихнуть машины в непонятные тоннели и так ездить - не получится.

Answer 1

[Adamos]

Прекрасный повод пересмотреть парадигму "начинаем работать на компьютере с офиса".
Не искать костылей, которые заменят привычные костыли Excel+VBA, а разрабатывать решения, которые не зависят от желаний левой пятки корпораций и правительств.
Например, Javascript на HTML-странице позволяет не только корректно повторить весь расчет, который народ шаманит в Ёкселе, но и читать-редактировать его без чудовищного геморроя с прыжками по ячейкам и мучительными попытками вспомнить, в которой что считается.
Нужно не только расчитывать данные, но и хранить их? База данных на Линуксе поднимается за 10 минут и не стоит вам ни копейки. Нужно обмениваться данными? JSON и XML не требуют никаких конкретных программ конкретной версии - ваша информация остается доступной, даже если вся M$-продукция объявлена вне закона...
Нужны документы для печати? PDF - открытый формат, и документ в этом формате не перекосит от того, что вы открываете его не в той программе, в которой создали. Более того - полно библиотек, которые автоматически создадут вам этот документ из ваших данных.
Нужно только сменить парадигму. Для будущего.

Comments

[Hemul GM]

Так себе ответ. Во-первых, это не костыль, а способ взаимодействовать с другими программами (через COM/ActiveX). Во-вторых, такое есть и в Линукс (подобие, конкретно для LibreOffice, например). В-третьих, обработанный документ легко и удобно редактируется после обработки, а такое часто необходимо.
PDF так себе редактируется (проблема не в отсутствии нормальных редакторов). Сам же Excel имеет куда больше возможностей, чем где-либо для подготовки документа к печати или отправки (подпись и прочее)

[Adamos]

Hemul GM, начав с JS, можно быстро прийти к API, если требуется взаимодействие. И оно, возможно, уже будет не только с программами, но и с серверами.
Для редактирования можно выкатывать и ODT/ODS, они тоже открыты и библиотеки есть. Но, по моему глубокому убеждению, офис в работе с данными больше мешает развитию, чем решает проблемы, и отказ от него позволяет находить более перспективные (а в перспективе - и удобные) решения.

[Денис _______________]

Проблема в решениях через WEBприложения в том, что любой табличный редактор по удобству ввода информации, когда у вас количество полей ввода несколько сотен, а то и тысяч, заруливает формы в минуса без вариантов. А если добавить что часть информации можно копировать протягиванием и через формулы, то становится грустно. Писать же табличный процессор с нуля - контрпродуктивно. Сам макрос нужен только для переноса подготовленных данных из типовой портянки в красиво оформленный и заранее подготовленный шаблон-файл, которых может быть десятки или сотни. Зачем тут базы данных - я ХЗ, Адепт, Алтиус, Хардроллер сделали именно так как Вы предлагаете, пользовались - работать неудобно.

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

[Adamos]

Денис _______________, цимес как раз в том, что вы (и, возможно, ваши смежники и контрагенты) приспособились к костылям офиса. К работе с таблицами, а не данными. Теперь вам кажется, что это удобно... хотя вы, разумеется, не заполняете вручную сотни и тысячи ячеек в Ёкселе. Просто привыкли использовать эти портянки вместо БД.
Да, увы, переход на веб-технологии - это революция. Его нельзя делать маленькими шажками, получается лажа.

[Денис _______________]

Adamos,
Я не имею ничего против WEB технологий, но человеку заполнять колонкой данные удобнее, чем скакать по полям ввода через кликанье мышкой. Собственно ПО должно быть удобным для того кто с ним работает и экономить ему время, а не писаться только ради того что бы использовать те или иные технологии, пусть даже самые передовые. Если на новых технологиях нельзя, относительно просто, создать и поддерживать такой код и формы, как на старых, то зачем такая технология нужна?

[Adamos]

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

[Денис _______________]

Adamos,
Так в этом и смысл что бы работать и оформлять документа на ПК. При чем тут мобильники, если под них это и рассчитано изначально и, более того, такие документы на экранах смартфонов никто не занимается офисной работой, хотя как бы приложения есть и даже есть возможность отправлять файл на печать. Просто сами по себе и Андроид и АйОС не рассчитаны на это. В лучшем случае это просмотр кем-то ранее созданных документов при минимальных правках, из-за которых почти всегда слетает форматирование. Просто не нужно пытаться устройства использовать в той роли, для которой они не предназначены. Ну неудобно будет и не нужно на смартфоне заполнять акт скрытых работ, а потом пальцем пытаться чертить исполнительную схему.
https://neftegazpto.ru/akty-i-formy/aosr

[Adamos]

Денис _______________, дело в том, что в современной системе, где работы будут отражаться в БД, акт не нужно будет "заполнять". Он заполнится имеющимися в системе данными сам - и лучше, чем вы натыкаете мышкой. И отправить его дальше по документообороту можно будет хоть с мобилы.
Но это та сторона дороги из желтого кирпича, отсюда ее еще не видно. Пока вы в пустыне Офиса, и домик никуда не летит.

[Apothecary]

Пробовали мы JS, очень медленно обрабатывает данные и делает необходимые нам расчеты, поэтому этот вариант точно не подходит тем, кто работает нормальными таблицами (50к+ строк) и проводит какие-то аналитические процедуры

[Adamos]

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

[Apothecary]

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

[Adamos]

Apothecary, либо уже реализовано в популярных CRM :)
Просто я немножко представляю разницу между колхозом в Ёкселе, в котором сложность и технический долг растут по экспоненте, и нормальным вебом, где можно решать задачи более простыми и естественными способами. Не преодолевая малопригодность выбранного инструмента в конкретно поставленной задаче.

[Apothecary]

Adamos, я говорю со стороны консалтинга, когда у каждого клиента "свой" огород. По сути вы предлагаете сделать аналог Power BI (как раз для нужных запросов верхнего уровня и по необходимости "проваливания" в более низкие уровни для анализа). Это довольно утопическая идея, с учетом что его в достойном виде нету даже и у профильных ИТ компания. В идеальной ситуации это имеет право на жизнь, а в реалиях (когда почти все туда-сюда гоняют эксель файлы) это потребует кучу времени ( и не только нашего, но и клиентского).

[Adamos]

Apothecary, это потребует написания конвертера - из таблиц Ёкселя в нормальные данные. Возможно, один раз.

[Apothecary]

Adamos, в том и суть вопроса, что эти конвертеры уже написаны на VBA, вот и велся поиск как с минимальными потерями их сохранить)

[Adamos]

Apothecary, нет. На VBA у вас написаны костыли для бега по таблицам, а с данными вы не работаете вообще.

[Apothecary]

Adamos, Дополнительно добавлю, что часто финансовым специалистам приходится вручную ковырять какие-то проводки, поэтому для части случаев "черный ящик с кнопкой" в виде БД может не подойти.

[Adamos]

Apothecary, понимаю. Но не верю, что они способны вручную перековырять 50k проводок ;)

[Apothecary]

Adamos, Конечно нет, но если итоговые небольшие таблицы даже завязать на данные, которые выдает БД, все равно останется вопрос, что там "наворотила" бд и можно ли ей верить, корректно ли все учитывается и тд. Часть этих проблем, наверное, можно покрыть каким-то дополнительными чеками, но в некоторых случаях проблема остается. А в некоторых сферах это довольно щепетильный момент.
Проблема в том, что таких "НО" при желании придумать можно много(
Согласен, что БД во множестве случаев быстрее, удобнее и практичнее экселей, но у таблиц тоже есть свои плюсы.

[Adamos]

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

Answer 2

[alfss]

https://wiki.openoffice.org/wiki/Python_as_a_macro... LO, OO. Запрета на использования их нет в РФ , даже при регистрации своего ПО их можно указывать как часть системы .

Так же как писали до этого люди . Потом можно перейти на решения web + lang + db .visual studio code есть под Linux и его можно использовать , насколько закроет ваши потребности , не знаю .

Так же если у вас есть какие-то данные которые нужно обрабатывать из таблиц и потом делать новые табличные данные , я бы рассмотрел связку xlsx,ods -> python + pandas -> xlsx, ods

Answer 3

[Apothecary]

Расскажу опыт со свой стороны - сфера финансов, работа с большими таблицами (эксельевскими, не БД), в среднем от 100 до4 00к строк.
Послел речерча open source решений, решили остановиться на LibreOffice. Работали на винде, мой комментарии:
1. Очень нестабилен, частые вылеты, даже на небольших объемах данных (до 50к строк);
2. Хоть и пишут про какую-то совместимость с VBA, но... Те макросы код которых полностью коннектиктся с библиотекой либрой будут работать, но сразу почти ничего не коннектится (причем не работают базовые вещи, типо поиск последней заполненной ячейки или использование словарей). Использовать частично VBA и LIbreOffice язык не получится (были идеи просто переписать те методы, которые не работают из нативного ВБА), поэтому для успешной работы уже написанных VBA макросов придется писать их заново. Не с нуля конечно, но целиком.

Интересно какие еще решения находили люди, так что подписался.

Comments

[Adamos]

Ну, в вашем-то случае нормальное хранение данных в БД и нормальная работа с ними через SQL, специально для этого созданный - просто-таки очевиднейший путь, а попытки наколхозить те же самые грабли в LO - просто синдром утенка.

[Apothecary]

Adamos, ну когда уже написаны механизмы, (к которым тоже привыкали), которые решают поставленную задачу за час (а в ручном режиме требовало 10+ часов), естественно хочется продолжить их использовать, а не придумывать и пересаживать людей на что-то абсолютно другое.
Мы когда мессенджер то меняли, народ плевался :D

[Adamos]

Apothecary, я давно админю, перевел свой офис на Линукс и представляю инерцию пользователей.
Но если то, над чем ваш Ёксель сейчас пыхтит час, будет выдаваться пусть не в реал-тайме, но за пару минут - есть надежда на понимание ;)
Исключая, конечно, тех пользователей, которые тратят этот час на трудовое чаепитие.

[Apothecary]

Adamos, Лично для меня в ваших советах возникает основной вопрос - не как сделать эти расчеты и в чем, а как сделать юзер-френдли интерфейс без привлечения кучи новых специалистов.

[Adamos]

Apothecary, как силами ковырятелей макросов написать CRM? Боюсь, это задача о семиугольном треугольнике.
Без того, кто разбирается в современных технологиях, вам из болота Офис-Убер-Аллес, конечно, не вылезти.

[Apothecary]

Благо с лицензиями вроде разобрались, так шо пока сидим в болоте нашем :D

[CityCat4]

Apothecary, Ненадолго. Уж простите, это поведение страуса - башку в землю, не вижу зла, не слышу зла, не делаю зла... Сейчас или через пару месяцев, или через полгода - M$ или сама уйдет или ее "уйдут" (а скорее всего и то и другое одновременно). Крякать будете? (Не в смысле издавать звуки, конечно же)

Таблицы такого размера - дичь.

Answer 4

[Игорь Махов]

Попробуйте МойОфис с Lua: https://habr.com/ru/company/ncloudtech/blog/575336/

Comments

[Денис _______________]

МойОфис с Lua не позволяет сохранять открытый лист в файл на диске, то же касается OnlyOffice с JS, это если не учитывать, что доступ к OS. заблокирован и очень низкая скорость записи в ячейку. Поле 1000 х 1000 ячеек заполняется порядка 31 часа, VBA справляется за 30сек, за 6 минут StartBasic Open/LibreOffice. Продукт не вытягивает на текущий момент, может допилят в будущем.

[CityCat4]

Спасибо, продуктом созданным для попила бабла пусть кто-нибудь другой пользуется...

[Никита Преснов]

Денис _______________, эа то на суперсовременном электроне

Answer 5

[calculator212]

3. LO и OO открытое ПО, но не входят в реестр российского ПО, однако многие российские дистрибутивы Linux поставляются именно с LO.

Честно говоря не совсем понятен этот пункт, вы можете использовать LO ,т.к.законопроект запрещает закупать иностранное ПО, про open source ничего не говорится. Во-вторых запрет идёт не для всех подряд сфер, а для ограниченной области. На хабре вам в комментах писали, что можно увелечить производительность LO при необходимости. В целом конечно лучший вариант написать свое ПО для работы, но как я понял этот вариант не подходит.
Вы конечно можете предположить, что LO тоже могут запретить, но это маловерятно, т.к. этот пакет уже используется в astra linux, который используется для работы с критической информацией немного инфы. Поэтому если нет желания писать свой софт стоит выбрать LO.

Comments

[Денис _______________]

Честно говоря не совсем понятен этот пункт, вы можете использовать LO ,т.к.законопроект запрещает закупать иностранное ПО, про open source ничего не говорится.

publication.pravo.gov.ru/Document/View/0001202203300001
Указ Президента РФ до 2025 года (пункт А) запрещает покупать иностранное ПО без согласования и одобрения Федерального органа исполнительной власти, а с 2025 года (пункт Б) запрещает использовать иностранное ПО совсем, без скидок на платный/бесплатный/свободный/несвободный. При этом форматs как MS Office, так и OO/LO в других нормативных документах допустимы к обмену между заинтересованными лицами. И да, данный Указ относится только для органов гос.власти и Заказчикам, которые работают на объектах КИИ. Соответственно это ограничение рождает вопросы, т.е. то что не запрещено разрешено?

Все Подрядчики будут вынуждены подстроиться под вкусы и локальные требования своего Заказчика, для того что бы было меньше проблем из-за войны форматов. LO поставляется комплектным с большинством известных мне дистрибутивов Линукса, но вот с российскими офисами не все так однозначно, потому что с 2025года на них должны перейти те, кто работает с КИИ. Душераздирающее зрелище.

Соответственно формат LO/OO точно будет востребован, однако какой из двух офисов нашей, отечественной разработки (МойОфис или Р7-Офис) будет наиболее широко распространен - это вопрос, т.к. это напрямую влияет на совместимость модулей.

Во-вторых запрет идёт не для всех подряд сфер, а для ограниченной области.

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

На хабре вам в комментах писали, что можно увелечить производительность LO при необходимости.

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

В целом конечно лучший вариант написать свое ПО для работы, но как я понял этот вариант не подходит.

Я ставлю для себя написать такое ПО/надстройку/макрос, который обычный пользователь сможет использовать при минимуме знаний и телодвижений. Это не всегда оптимальный путь, потому что было много критики о том что я храню данные в таблице эксель, но это очень удобно с т.з. просмотра, чтения, контроля информации и ввода информации для заполнения актов, на основе типовых шаблонов. Более того есть платные программные продукты, которые решают ту же задачу, имеют больший функционал, но неудобны исполнителям для ввода, на котором они теряют уйму времени. Зато удобны для анализирования и контроля с т.з. проверяющих. Просто мной и разработчиками такого ПО разница именно в целях и задачах. Соответственно разный выбор методов разработки и внедрения.

Поэтому если нет желания писать свой софт стоит выбрать LO.

Макросы это тоже софт... пока что я перед выбором - условно вытащить во внешний модуль, а таблицам оставить функционал хранения/ввода данных, а так же выводных форм, либо вешать это на один файл с макросами, как для экселя, но в LO. Судя по всему придется работать с питоном.
Надо пробовать, возможно придется выбор еще ни один раз корректировать. Но, по крайней мере, в рамках обсуждения приходит некоторое (не окончательное) понимание. Спасибо

[calculator212]

а с 2025 года (пункт Б) запрещает использовать иностранное ПО совсем,

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

[Adamos]

Денис _______________, на самом деле, если вы не работаете со старыми форматами типа XLS и все-таки полностью перешли на XLSX/ODT, вам в принципе не обязателен офис для работы с этими файлами.
Javascript вполне может вынуть данные из XLSX, провести над ними расчет и сформировать таблицу результатов. Можно создать HTML-страницу с включенными в нее скриптами, на которой будет кнопочка "Открыть файл XLSX" - и после его выбора появляются кнопочки "скачать результаты расчета", "скачать прочие нагенеренные из этих данных документы".
Открываться и работать эта страница будет в голом браузере, который уж точно будет на любом клиентском компьютере.

[Денис _______________]

Javascript вполне может вынуть данные из XLSX, провести над ними расчет и сформировать таблицу результатов.

С этим прекрасно справится тот же python или чем сейчас модно работать с таблицами. Я тут в рамках статьи попробовал JS макросы от OnlyOffice и что-то не зашло... конечно за пару вечеров нормальное представление об языке не составить, но отсутствие нормальных многомерных массивов с жесткой адресацией и проблемы повторного использования переменных меня напрягли. Lua тоже, кстати, не зашел. Возможно зря, но я учился программировать в эпоху Basic/Pascal/C/Delphi/VisualBasic, хочется чего-то похожего.

Можно создать HTML-страницу с включенными в нее скриптами, на которой будет кнопочка "Открыть файл XLSX" - и после его выбора появляются кнопочки "скачать результаты расчета", "скачать прочие нагенеренные из этих данных документы".

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