Михаил Л,
у вас какой-то очень спортивный интерес ))
если я правильно понял, то изначально данные лежат в 1С.
какие задачи вы выполняете выгружая эти данные в текст/эксель/другую БД? нет ли возможности решить эти задачи средствами 1С ?

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

что мне нравиться в работе с данными, так это то, что любую задачу можно решить несколькими способами.
в вашем случае:
1. полученный excel раздербанить на месте на нужные данные в соответствии с таблицами в БД и несколькими движениями втягивать потаблично. способ дурной на мой взгляд
2. средствами MSSQL (например через bulk insert) втянуть все данные в промежуточную таблицу и уже оттуда раскидать по целевым.
способов втянуть данных несколько, рекомендую вот это почитать: https://docs.microsoft.com/ru-ru/sql/relational-databases/import-export/bulk-import-and-export-of-data-sql-server?view=sql-server-ver15

и здесь много раз обсуждался импорт и местами последующая обработка: https://www.sql.ru/forum/afsearch.aspx?s=?????? ?? excel&submit=?????&bid=1




1С не хотите освоить? ))

тут многие работающие, поэтому столь незначительные вопросы оставляют в лучшем случае на вечер. ))

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

если сильно не ударяться в процесс, то я сперва заполнил бы из имеющегося набора данных справочники примерно так:

insert into [Клиент]([id_kl], [Клиент])

select
ROW_NUMBER() OVER(ORDER BY [Клиент] ASC),
[Клиент]
from [Baza_VR].[dbo].[vremen]
group by [Клиент]

--select * from [Клиент]

затем бы уже заполнил основную таблицу [prodagi] с привязкой к заполненным справочным таблицам.

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

да в принципе все то же самое как и в предыдущем случае, просто выдергиваем полученные в справочных таблицах айдишки и заменяем ими значения, примерно так (на базе не проверял):

insert into [prodagi]
([id_kl], [id_mg], [id_gr], [id_tv], [СчетФактура], [Дата], [Кол-во], [Сумма])

select
(select id_kl from [Клиент] where [Клиент].[Клиент] = [Baza_VR].[dbo].[vremen].[Клиент]),
(select id_me from [Менеджер] where [Менеджер].[Менеджер] = [Baza_VR].[dbo].[vremen].[Менеджер]),
(select id_gr from [город_регион] where [город_регион].[регион] = [Baza_VR].[dbo].[vremen].[регион] and [город_регион].[Город] = [Baza_VR].[dbo].[vremen].[Город]),
(select id_tv from [Товар] where [Товар].[Товар] = [Baza_VR].[dbo].[vremen].[Товар]),
[СчетФактура],
[Дата],
[Кол-во],
[Сумма]
from [Baza_VR].[dbo].[vremen]

--select * from [prodagi]

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



если мы имеем справочные таблицы то счищать и перезаполнять их заново без перезаполнения скажем условно одной из таблиц фактов - возможное нарушение целостности данных. И чтобы этого избежать надо их тогда немного переделать.
Как бы делал я в данном случае:
в справочных таблицах на поле с ID добавил бы свойство IDENTITY, чтобы не заморачиваться с присвоением этого идентификатора.
Тогда при заполнении этих таблиц я бы просто проверял наличие значений, примерно так:

insert into [Клиент]([Клиент])
-- заполняем справочную таблицу, делаем практически все то же самое
select
[Клиент]
from [Baza_VR].[dbo].[vremen]
-- но добавляем условие когда данные по клиенту уже есть в справочной таблице и их добавлять не требуется
where
[Baza_VR].[dbo].[vremen].[Клиент] not in (select [Клиент] from [Клиент])

все это прелестно в случае когда в изначальных данных из 1С никто не балуется, например не переименовывает клиентов

Далее.

а зачем?
структура таблиц одна, логически данные - единый массив по продажам, он интересен именно в целостном виде.
зачем разбивать по периодам, если мы запросами и так получим нужные данные и из одной таблицы, зачем постоянно держать в голове эту возможность и необходимость их union?
допустим в апреле начальник запросит данные по продажам какого-то менеджера за условно последние полгода или два года (тут надо выдернуть данные с ноября 2020 года из одной таблицы и выдернуть данные по текущему году с другой), имея все данные в одной таблице мы легким запросом просто выдергиваем то что нужно и выдаем готовый отчет, без ерундистики с объединениями
Опять же, если в изначальных данных никто не балуется, то пользуясь тем что у нас может пропасть необходимость перезаполнять справочники, мы можем не перезаполнять таблицу продаж каждый раз, а просто также добавить в операцию заполнения таблицы продаж
insert into [prodagi]
условие когда данные уже есть, и их вставлять не требуется
ну если на пальцах, то как-то так это все выглядит.