DenisDenis
Есть несколько, схожих по структуре, документов Excel
Это понятно. Даже если их не было бы, нужно было бы всё равно писать код для автоматизации этих действий так, как будто они появятся и будут любых размерностей, даже если они не появятся и размерность всегда будет одна.
Чем более общую программу ты пишешь, тем в большем числе задач ты можешь взять готовый код программы и применить его, лишь слегка переделав - то есть не писать код с нуля неделю, а поменять код за полчаса и получить готовый результат. Высшее мастерство - писать код программ настолько общим, что в любых будущих вероятных задачах его можно будет использовать сразу без доработки - то есть неписать код с нуля неделю, а поменять код за ноль минут и получить готовый результат. Это напоминает конструктор Lego: когда тебе нужно написать программу, ты из уже готовых программ, ранее написанных тобой (а при большем опыте (в плане лицензирования) и написанных другими), выбираешь подходящие большие куски кода, как кирпичи, и строишь из них совсем другое сооружение, на что уходит всего один день, а не один месяц.
Если же ты пишешь не общую программу, а конкретную, то это выглядит удобно на первый взгляд и кажется правильным. Только вот весь облом наступает тогда, когда вдруг тебе приходят таблицы новых размерностей, а ты написал код только для размерности 4x4. И тогда тебе нужно с нуля писать код для новой размерности. И потом у тебя два кода работают для разных размерностей. А вскоре появляется третья размерность и ты начинаешь проклинать себя за лень

Потому что ты когда-то давно поленился написать общую программу, которая была бы одна и справлялась бы с любыми таблицами, какие бы они ни возникли в перспективе, а теперь ты мало того что время потерял на написание повторных программ, так ещё и это нужный результат не дало, так как риск появления новых размерностей всё так же остаётся, сколько бы ты конкретных программ ни написал.
DenisDenis
Таблица 1 - это то промежуточное решение на котором мне пришлось остановится.
Открою тебе секрет. Какие бы ты таблицы ни брал - начальная, промежуточная, конечная - в программировании они все считаются промежуточными. Всё это связано с тем, что любую из таблиц можно получить откуда угодно (хоть генерировать на лету) и любую из таблиц можно в любой момент преобразовать во что угодно (хоть в словесные фразы, хоть в изображения, хоть в звуки). Поэтому совершенно не важно, на каком этапе получена таблица. Любая таблица рассматривается как возникшая из ниоткуда и идущая дальше на вход куда угодно и зачем угодно.
DenisDenis
Чтобы достигнуть своего результата в виде таблицы (2) можно:
1. Забыть про python, и вручную, воспользовавшись встроенным механизмом Excel, “консолидировать данные” и в пару кликов мышкой привести к желаемому виду;
2. Воспользоваться уже разработанным на python, аналогичным “консолидация данных” Excel, методом, который я хотел бы уточнить у вас или участников форума, если таковой существует;
3. Доработать код, основываясь на других возможностях языка python. Возможно Вы подскажете фраймворк, как инструмент подходящий для решения подобных задач.
Если забыть про питон и использовать встроенный механизм Excel, а потом кликать мышкой, что будет. 1) Когда-то возникнет задача, которую Excel не сможет решить из-за отсутствия встроенных средств. 2) Когда-то поток в один-два-десять файлов в неделю превратится в поток в одну тысячу/пять тысяч/десять тысяч файлов в день. Как думаешь, что произойдёт с мышконажимателем, будь он даже настоящим коммунистом? Он просто физически по времени не сможет их обработать.
А что может питон? Питон может и любые задачи решать, и может решать их сам, не требуя наличия человека во всём этом процессе. К тому же, если ты всё-таки разместишь это всё на каком-нибудь компьютере в Интернете (как это всё обычно делается в распределённых архитектурах), то вряд ли там будет Excel, потому что Excel сделан для человеков, сидящих за одним компьютером, а питон сделан для компьютеров, которые могут распределять работу между собой.
Так что я против VBA в Excel в данном случае и вообще, хотя вроде на первый взгляд твоя задача очень близко к VBA расположена. Почему не VBA? Потому что VBA - это максимум разгрузка человека, который там на кнопки нажимает, и нахождение в пределах сисадминских правил, которые у тебя в организации определены (запрещено ставить питон там и тому подобное; бывают также изолированные сети, которые вообще не подключены к Интернету, а для питона он нужен, потому что часто ты хочешь что-то использовать в питоне, пытаешься это сделать, а этого нет, потому что оно не установлено).
По поводу того, есть ли в питоне великий метод консолидации из Excel'я. Все эти умнейшие методы Excel'я - это такая мелочь по сравнению с возможностями питона, что об этом говорить даже не стоит. Питон может в сто раз больше, чем Excel в плане всего (математика, анализ, преобразования и прочее). Поэтому ты можешь написать эту консолидацию (и даже лучше, чем эта консолидация) на питоне и менять её как угодно, тогда как в Excel'е ты должен изучать, что там Excel тебе предложить из своего ассортимента.
В плане того, как это написать и есть ли фреймворк. Ты можешь написать это без фреймворка (чтобы не создавать зависимость твоей программы от наличия или отсутствия фреймворка правильной версии и тому подобного). Также ты можешь использовать фреймворк типа pandas, но будь готов его изучать. Далеко не всегда фреймворки пишут такие же классные ребята, как те, которые пишут питон, где всё легко, просто и понятно (документация есть подробная и только по делу, стиль хороший типа PEP8 и тому подобное). Во фреймворке может быть и херовая документация, потому что человек два слова связать не может в жизни, зато он код программы хорошо пишет; и интерфейсы у фреймворка могут быть дебильные, когда функции называют бредово и не поймёшь где какая функция, вызываются нелогично, какие-то вещи не параметризованы и из-за этого тебе функция навязывает свою хрень, которую ты поменять не можешь через параметр, как это обычно принято закладывать при проектировании функции; и сдохнуть этот фреймворк может или куда-то пойти не в ту сторону во времени, что придётся от него потом отказываться, хотя ты там его изучал хрен знает сколько времени со всеми его выпендрёжами. Вот так привязываешься к какому-нибудь Django, а он тебе потом говорит “а я третий питон не хочу, буду на втором и, может быть, когда-нибудь буду на третьем”, а тебе-то третий питон нужен прямо сейчас, потому что он почищен хорошо от разных косяков, в то время как на втором питоне надой фигнёй всякой страдать вечно. И из-за фреймворка ты не можешь слезть со второго питона, например. Вот это связь, зависимость. Ты привязал программу к фреймворку, а потом не можешь программу двигать дальше, делать её современной, потому что фреймворк её тянет в прошлое. И отвязать ты её не можешь от фреймворка, потому что много кода написано, завязанного на фреймворк.
Так что думай, отвязывайся от Excel'я при первой же возможности. Он тебя тянет в прошлое - клики какие-то там мышкой, консолидации немногочисленные и ограничение у него ещё в таблицах на количество строк в размере около 30000 в наше-то время, когда уже миллиарды строк пришли (большие данные).