Импорт таблиц офсиных пакетов в БД

Разработчики все правильно сделали. Если еще и формулировка была такой же, как тут, то скажи спасибо, что морду не набили.

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

что конкретно с формулировкой не так? Что то не понятно? Что они сделали правильно, чуть лишившись выгодной работы?
касаемо «набивания морд», - команда разработчиков не фирма аля чп «кактус» из которой видимо вы, а команда профессионалов. Слово «агрессия» у недоумков сразу ассоциируется со словом «оскорбления» похоже.

Balantay, т.е. тут вопрос сложности реализации как я понял с ваших слов. Требовать поддержки полного функционала разумеется нельзя, Банально арифметические функции и связи ячеек. При таких требованиях это возможно? И насколько трудоёмка хотя бы на вскидку такая задача?

Вашей конторе придётся подучить вашего «штатного программиста» пользоваться БД или заменить его другим программистом, который уже умеет пользоваться арифметическими функциями, предоставляемыми базой данных.

Странные разработчики, могли бы засунуть в БД файлы как BLOB и условия выполнены, все внутри и файлов на сервере нет. ЛОХИ!

создания нашим штатным программистом БД необходимых отчётов

Пожалуйста, пожалуйста...
Изучите, что такое OLAP. Изучите информацию о Pentaho и Jasper Reports и попросите девелоперов интегрировать с ними и больше не пугайте их НЕОЖИДАННЫМИ ТЗ, напоминающие изобретение пятиколёсного велосипеда с треугольными колёсами, когда есть нормальные транспортные средства. Более того, как человек, пол-жизни занимающийся анализом бизнес-статистики, могу даже проконсультировать (бесплатно) или составить ТЗ (за деньги).

Связи ячеек в электронной талице сохранить в таблице БД? Как Вы это вообще видите? В БД реляционная модель, и связи там совсем другие. Даже в MS Office в Access доступ только к данным в таблицах EXCEL.

Скорее всего имеется в виду генерировать таблицу по структуре как в документе, и к ней сразу приделывать триггеры, которые после insert-а и update-а будут пересчитывать по формулам из этого самого документа значения

Так это view можно сделать без триггеров... А чёрт, там же разные формулы!
Я за готовые проверенные решения.

Нужно для начала определиться с ТЗ, навскидку такое оценить невозможно.

Что они сделали правильно, чуть лишившись выгодной работы?

Я вот сомневаюсь, что ТАКАЯ работа может быть выгодной. Они все сделали правильно. Предполагаю, что реакция анонимуса на предмет «набить морду», просто была первым, что приходит в голову после такого предложения. Так что он прав.
По теме, надеюсь Вам уже все разъяснили. Существует куча систем создания отчетов, не такие уж и сложные в освоении.
А называть «программистом БД» человека которому нужно то, что вы написали в требованиях - нельзя. Это юзвер.

Для кложуры видел клёвую либу: http://www.infolace.com/blog/2015/02/10/generating-beautiful-excel-reports-wi...

Странно что никто больше до такого не додумался, и во всех других ЯП есть максимум средства по дрочеву отдельных ячеек вручную из программы.

импорта офисных документов типа Excel

Ой, прочитал вначале как экспорта. Тогда да, запрос не очень понятный.

нашли ирл такого же умного человека как Вы, который всё объяснил и помогает. Спасибо.

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

Shadow, для меня это звучит как «бла бла бла бла», я ж не «компьютерщик». Обыкновенный пользователь арча. За предложение спасибо.

anc, насмешили, какая такая? Тебе платят деньги за работу. В счёт фактуру даже сумма за составление ТЗ входит. Не знаю с какой вы планеты, но тут на планете земля «клиент всегда прав...пока он платит бабки». Тут народ мне пытался помочь вообще бесплатно, поэтому покоробила нас их несговорчивость, а ваш пост посмешил.

Встречаем очередного «эфектив манагера» на ЛОРе. Гнать Вас таких паразитов надо на job.

я ж не «компьютерщик»

Это популярные инструменты анализа бизнес-статистики, применяемые, например, «менеджерами по продажам» и аналитиками.

Это для анализа физиков или юриков ? А что за банк, если не секрет, решился на закрытие своей грудью столь сложного фронта ?

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

Дык, в БД кинуть формулу из удобного интерфейса не? Oracle (не БД) задал стандарт, много лет на нём всё считают. Если жаба на оракл душит - данные из пентахи прикрутить к шаблону excel, и пускай оператор АРМ сам считает. Но лучше оракл: там в его olap много плюшек для кастомизации.

Если это оно, то расчет фин показателей юрика еще >15 лет назад был талмудом на ~100 страниц a4. Там пох на вендора БД, я в 98 писал спецсофтину на dbase со встроенным табличным процессором, там не прикрутишь по шаблонам, исходные данные - баланс (должен быть теоретически) а у разных предприятий будут разные счета, в зависимости от сферы деятельности, практически может быть надо собирать данные с разных балансов и ручными поправками и неясной адекватностью цифр, ибо где отчетность, а где жизнь. Это тот случай что задача формализуема больше теоретически нежели практически. Любой олап тут будет бантиком на последней стадии, тут полуручная работа во все поля.

Так сидит бабушка на должности инженер-поограммист. Вот и зовут ее программистом

расчет фин показателей юрика

Это ж стандартный инвестанализ.

формулы то можно выдрать и сохранить, только это как хранилище будет т.е. считать это уже не очень реально

какой срок разработки и сколько разработчиков?

Нужно писать фронтенд легковесного икселя, но и то с большими допусками

Хороший вопрос почему есть бд и электротаблицы и почему до сих пор этот разрыв существует.

Sometime такими задачами хитро вбрасывают на рынок очередной продукт от племенного производителя ишаков или гадалок...

В том числе.

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

Shadow, не встречал ни в одном банке. Везде пользуются «экзелем» кучей связанных файлов, «везде» - это еврозона и часть азии. Возможно какая часть софта у коллег и есть это «бла бла бла», но это не суть.
Суть в том, что АРМ вспомогательная часть, которая должна брать часть расчётов на себя, так как требуется мобильность, а расчёт на ноуте «экзелем» может достигать 30-40 часов.

handbrake анализ разрывов и процентные риски в основном. Это как расчёт чёрных дыр, только вместо них таймфреймы. Формулы там выглядят очень громоздко, но они банальная совокупность циклов, сложений и умножений. Ветвлений условий там практически нет, всё это делается руками.

Формулы там выглядят очень громоздко, но они банальная совокупность циклов, сложений и умножений.

Ну вот так бы и написали. Тогда понятна реакция программистов, и ваша реакция. Недопоняли друг-друга.

Недопоняли друг-друга.

Да как же тебя понять, если ты ничего не говоришь, собака! (С) Иван Васильевич ...

А скорее даже: «Нам надо нарисовать 7 красных параллельных прямых» ... :))))

Походу программеры поняли что надо брать бабло, раз дают и заниматься ИБД. С чем заказчика и поздравляю.

Поддержу. И от себя добавлю, в excel на основе формул, что либо сложное и с большим объемом лучше не считать. Большая вероятность получить ошибку в результате. Самое распространенное: это когда число оказывается не числом (правда с 2003-го оно почти всегда выделяется, именно почти, но на большом объеме можно не заметить), элементарные ошибки в номерах ячеек и если это касается финансов, пользователи забывают о необходимости использования округления в самой формуле. Мне приходилось «по просьбам трудящихся» писать на vba, жуть конечно та еще, но вот заодно при обработке я проверяю уже существующие результаты высчитанные по формулам, ни одного случая не было что бы не находились ошибки. А люди этими данными не один год пользовались считая их достоверными.

да, и разрывы ликвидности и кэшфлоу тоже, писал я эту вашу хрень почти 20 лет назад :)

Везде пользуются «экзелем» кучей связанных файлов, «везде» - это еврозона и часть азии.

Ну и ссзб. Я еще во второй половине 90-х участвовал в проекте который разрабатывал отдел аналитики, как раз на замену кучи всяких там экселей. Мой вклад там был небольшой как раз приложение с локальным хранилищем для офлайновой (без доступа к основной БД) обработки данных с которыми работает пользователь. Btw сама идея принадлежала нач. отдела аналитики, и он еще в те годы показал неэффективность старых методов, и напоминаю, что тогда в этой стране как-то не модно было вкладываться в «непонятно в какое-то там ИТ».