наткнулась на пример на python Time Series Analysis, Regression, and Forecasting - с формулами, понятными для перевода, но без сезонности

почему смотрите в сторону Excel ?
чтобы подстраиваться - нужна статистика и аналитика -- в рамках Excel и Access невозможно создать качественную CRM -- да ещё и под управлением админа, вероятно из сети... облачные решения не предлагаю, не знаю, насколько хорошо они поддерживают многопользовательский доступ к БД
P.S.
для выбора платформы, сервера, хостинга и, соответственно, языка реализации вашей CRM -- лучше уточняйте размер бд (план на количество клиентов) и количество пользователей (помимо админа) заранее.
===
не претендую = не считаю, что вам нужна помощь Excel-специалистов

наверно, как-то так (первичные/(повторные+первичные))*100% = %первичных, значит  100-B2/(C2+B2)*100=%оставшихся
и высчитывайте тренд и сезонность для этого процента продления ==> ответ тоже будет интерпретироваться как процент продления -- возрос или упал... тестить сама не буду, но по логике задания, видимо, в этом русле
? похоже, ещё понадобиться вернуться обратно от процентов к оплатам...  по логике: отдельно спрогнозировать первичные, отдельно спрогнозировать повторные и сложить, ИЛИ сразу прогнозировать совокупный показатель продаж (первичные+повторные), потом умножить на процент продления (лучше долю, см. p.s.), взятый из отдельного прогнозирования его самого в начале...
а они вообще есть ? и какие?
p.s.
там 100% в вычислениях лучше заменить на 1 (чтобы получать долю от 1), а процент просто форматом ячейки задать... чтобы лишний раз потом не возиться с делением на 100 при возврате от % к сумме
p.p.s.
приложила только расчёт процентов от общего - (поправила формулу вчерашнюю), прогноз вам надо делать, как в прошлой вашей ветке

ИТОГ:
вы сделали расчёт прогноза для 1-го вашего задания по Мультипликативной модели:

моя ошибка была в том, что я не изъяла тренд ещё, когда считала коэф-ты сезонности. На листе Задание ваш расчёт верный (для одного товара).
Для бОльшего количества товаров - добавление ещё одной размерности в таблицу понадобится (назв. товара), что усложнит расчёты и удобнее будет делать либо макросом, либо средствами Power Q или Power P или Power BI, либо на др. языке (поддерживающем распараллеливание расчётов для скорости их выполнения)

поздравляю! спасибо за ответ!
но на новые вопросы (если будут) лучше откройте новые ветки - согласно Правил форума (1 тема - на 1 вопрос) - чтобы модераторы не закрыли...
и по поводу вашего Ника могут сделать замечание - лучше что-нибудь читабельное (чтобы к Вам можно было обращаться не по буквам).
***
успехов!
спасибо за интересную тему
P.S.
Эту могут переименовать в Прогноз продаж с учётом сезонности
- пример можно см. здесь,  для общего развития по логистике здесь

введите суммарную выручку за 2021 : 121920144 ? если сойдётся, подумаю, как изобразить в excel

а что с чем не сходится тогда?)

можете приложить правильные ответы, на которые надо выйти в итоге? (если есть)... не обещаю, но посмотрю, или кому-нибудь тоже интересно будет, на что надо выйти....

опишите как считаете сезонные коэфициенты?
правильно ли приложила? (без тренда)

Планирование продаж сезонных товаров с учетом меняющихся экономических условий
Пример 2. Простая линейная регрессия (прогноз на 9-й месяц) - тут формула с ошибкой - правильнее - CTRL+SHIFT+ENTER
P.S.
разделите проблемы в соответствующие ветки - опишите логику расчётов - это форум по excel, не по аналитике, - здесь лучше приведите правильные ответы, выйти на которые помогут специалисты по Excel...
p.p.s.
можете от таймсерии отнять тренд и разделить на сезонный коэффициент = таймсерия, очищенная от тренда и от сезонности
***
что такое повторные продажи ? и что вы хотите с ними сделать? нужны пояснения

сама отвечу (тайминги не проверяла): (pip jaxlib, jax) JAX  64x и его Just-in-time (JIT) компиляция - для Python:
p.s. а вообще в реализации оптимизационных пакетов - очень много асинхронности и даже многопоточность  -- что даёт существенное ускорение работы генетического алгоритма для реализации на Python (корни которого всё равно c++)...в общем, если параллелить (програмно) самостоятельно GA-код (на чистом с++) - то не забывать включать асинхронность ) для ускорения на больших объёмах...
p.p.s. (и по логике очень много тестирования loss_and_grad в Numerical Solutions vs. analitical)... и на grad_mean и grad_std - internally in lib - в байесовских реализациях
p.p.p.s . NB oscillation & stochasticity of GD,  EMA momentum in gradient descent --Automatic Adjustment of Learning Rate and Momentum -- geeks
p.p.p.s. [dLdtheta] dynamics locally for quicker optimization/convergence, as well as [dxdt] dynamical solution itself (through backpropagation):
Working with the Lagrangian gives us a systematic way of finding optimal values
for Neural ODEs using Lagrange Multipliers
optimal control problem as an NonLinProblem
Lagrangian with a generalized kinetic energy term
Using Energy Equivalence to Determine Mass In Arbitrary Coordinates

Flowchart-диаграмма - здесь,
а здесь - GENETIC ALGORITHMS IN EXCEL
-- для сравнения (если кому будет интересно) - сама не тестировала...
p.s.
кто как смотрит на выигрыш от многопоточной реализации этого алгоритма? (понятное дело, что не в Excel) - но будет ли выигрыш большим? т.е. нормально ли параллелится этот алгоритм? (на C++ или Python)... или, может, async ускорит?

Excel Solver spectrum (Поиск Решения) - или сразу по Timeseries - может стать более подходящим инструментом Excel (эволюционные и генетические алгоритмы для различных [мета]эвристик) - дадут более адаптивные решения для реал данных, поскольку для линейных методов надо сделать очень много apriori предположений... только алгоритм всё равно д.б., желательно, сгенерирован собой... а в Excel, может, ещё и sampler
... Успехов

и да вы правы - в зависимости от выбранной модели - вы можете получить различный Тренд - например, как здесь - убрав seasonal-составляющую (используя SARIMA модель) по сравнению с просто ARIMA --  Slope тренда сразу уменьшается и не выглядит так впечатляюще - поэтому как вы разбросаете ваш ряд на трендовую, цикличную и шумовую составляющую (компоненты) зависит только от ваших предпочтений (?), но лучше если будет зависеть от корректно выполненного анализа автокорреляционных реалий вашего временного ряда

выделите Unique
потому что при Full вы берёте всё из  Left_table +(union) из Right_table только те, которые не дублируют пересекающуюся часть в 2х множествах: т.е. Right с условием Where key_joined.value Is Null...  == вы при Full делаете Декартово произведение
p.s.
см. Дискретную математику - работа с множествами... A × B = {(x, y) | x ∈ A, y ∈ B}

############# по Прогнозированию временных рядов:
всё что можно посоветовать - это начать изучать тему - прежде чем этот Тренд ложить в основу своих выводов и степени их доверия  ...
например Steps of Building the ARIMA (AR + MovingAverage) model:
(только на 6м шаге прогноз! )
#############
P.P.P.S.
по степени доверия (вложила файл, по которому можно судить о приемлемости модели) - примерно такой модели по вашим данным я, может, и доверила бы, но выбранные p и q меня смущают (не уверена, что их стоит делать одинаковыми)
... это только пригодность модели, потом делается прогноз (с учётом трендовой составляющей, цикличности и доверительных интервалов, которые характеризуются +/-3sigma для нормально-распределённых данных)...
- и в Остатках не должно быть автокорреляции...
и они должны иметь Гауссовское распределение (в жизни не всегда так бывает)
##############
По алгоритму (см раздел картинки ARIMA Algorithm Flowchart )
или что-нибудь по-новее Singular Spectrum Analysis - т.к. по сути анализ временных рядов и есть спектральный анализ для различных лагов (насколько понимаю) с определением частот, на которых наблюдается повышенная автокорреляция - для последующего её удаления (выделения в трендовую и циклическую составляющую) и финальной оценкой остатков (предпочтительно, гауссовского распределения) --
-- как только выделите компоненты - нарисовать их на графике не составит труда - в зависимости от выбранной модели: additive или multiplicative (как указала выше: отнимать составляющие части или делить)

P.S.
ПО созданию модели Прогноза
##############  по Стационарности (т.е. чтобы факторы не коррелировали между собой - важно при лин. регрессии - e.g. AR, исследующая корреляцию ряда с самим собой, т.е. оценивая его подряды с заданным лагом на корреляцию между собой)
изначально надо делать тесты ‘Unit Root Tests’:
или здесь
- Augmented Dickey Fuller test (ADH Test)
- Kwiatkowski-Phillips-Schmidt-Shin – KPSS test (trend stationary)
- Philips Perron test (PP Test)
###
ADF test, where the null hypothesis is the time series possesses a unit root and is non-stationary. So, id the P-Value in ADH test is less than the significance level (0.05), you reject the null- hypothesis
The KPSS test, on the other hand, is used to test for trend stationarity. The null hypothesis and the P-Value interpretation is just the opposite of ADH test.
###
повторюсь, ваши данные нестационарны (к стационарности не приводила) - поэтому дальнейший любой AR анализ бесполезен (пока не приведёте к стационарности - можно брать первые разности - обычно этого достаточно)... и снова тест на стационарность
ИЛИ
############## потом Автокорреляционные факторы (PACF для AR и ACF для MA) м. помочь подобрать d,p,q параметры для AR моделей (не все нужны для всех моделей) -- (но это неудобно делать глазами, поэтому исп. лучше оптимизацию с проверкой по критерию правдоподобия AIC)
P.P.S.
вообще, автокорреляция может встретиться при регрессии любой зависимости, не только dx/dt, но для др случаев она встречается реже (зависит от рассматриваемых факторов-признаков и факторов-результатов) - но её надо принимать во внимание (если она есть) при описании зависимости

TS-ряд состоит из :
- детерминированный тренд
- стохастический тренд (сезонность и иная цикличность)
- стационарная ошибка (или остатки, или шум, или то, что остаётся после изъятия из TS-ряда тренда и цикличности
и 2 вида моделей: или все эти компоненты складываются (additive model) или все перемножается (multiplicative model)...
соответственно, чтобы выделить эти составляющие надо:
при additive model - отнимать, при multiplicative - делить = чтобы изъять соотв. компоненты, которых кстати может и не быть - поэтому сначала см., что они есть ?... - см. Автокоррелограммы - на выявление значимых частот цикличности и др. паттерны)
т.е. Algo (как изъять):
Python detrended = signal.detrend(df.value.values) ИЛИ вычитать/делить на трендовую составляющую, рассчитанную по вашим параметрам, например MovingAverage  ИЛИ как захочется...
seasonal тоже вычитать/делить в зависимости от типа вашей модели (additive или multiplicative)
... в Excel - всё ручками (выше давала линк на надстройку RealStatistics - там уже есть много полезных функций для анализа временных рядов)
##############
Остатки должны в итоге предпочтительно быть белым шумом (нормально распределены с mean=0 и std=const), но не всегда это бывает - зависит от вашей модели - mean м.б. просто const и std д. б. const в любом случае - чтобы данные считались Стационарными...
(по остаткам выше видно, что при такой декомпозиции на тренд/циклы/шум - остаётся какой-то неучтённый моделью паттерн цикличности - остатки идут волнами, а не норм. распределены с const mean и std)
############## по Декомпозиции:
и есть мнение , что есть алгоритмы декомпозиции получше (в tsa - объект STL) (или в prophet), чем классическая декомпозиция, которая в tsa объект seasonal_decompose - ...
ПО КАКОМУ АЛГОРИТМУ ВЫ БУДЕТЕ РАСКЛАДЫВАТЬ РЯД НА КОМПОНЕНТЫ - ВАШ ВЫБОР (обычно в smoother'ах State-Space моделей исп-ют Kalman-Filter) -- всё поддаётся описанию мат. формулами (формализации) и алгоритмами (из линков выше ComputationalStatistics даёт много возможностей для описания нужных алгоритмов)... но я предпочитаю готовые stat. библиотеки в Python (например, реализация SpectralSmoother, который smoothes the timeseries applying a Fourier Transform - в качестве примера алгоритма - стоит ли переводить на DAX?) и адекватную теор. базу по статистике  - избавляют от ручных расчётов (формул) -
- в Excel вроде нет ничего для анализа временных рядов, хоть по статичтике в ПакетеАнализа что-то есть для распределений - ишите Описательная статистика в Excel  -- и какие-то формулы  -- но для ан. временных рядов надо делать самому ...

приложу decompose для period=7 ваших Продаж этой ветки - не Оптимизировала, тест Дикки-Фуллера не делала, но остатки мне не нравятся, и цикличность тоже... после оптимизации график может быть получше  - для Dax это будет, наверно, очень тяжёлая операция
остатки не видны, чтобы делать валидный вывод...
p.s.
-- как решите делать валидные выводы, пусть эта ветка вам даст пищу для размышления.  (просто не люблю неверные интерпретации и необоснованные выводы, и вам не советую рисовать Тренд и искать Сезонность по параметрам из головы)  -- алагоритмически анализ timeseries вроде здесь, но тоже на англ. и тоже без оптимизации, а ручками искать best parameters - неудобно (не зависимо от языка)
Успехов

1) по ссылкам хотя бы графики посмотреть
2) по результатам (хоть своим хоть чужим) дать Интерпретацию для принятия решения по полученным данным
3) по файлу - никто не отрицал, что циклический граф можно выродить в дерево - здесь даже с неявными связями ... и дерево реализовать на функциональном языке (типа DAX)
4) по алгоритму поиска dx/dt=kx - лишь вопрос скорости, тяжеловесности и точности (бывает)
5) по реализации файла - когда нарисуете CI - увидите размер неопределённости вашего прогноза ... в добавок к смещению (относительно данных, полученных при др. условиях) ...
6) по полезности анализа timeseries - от нас вообще ничего не зависит: время идёт само, продажи формируются спросом... хоть маркетологи и думают, что формируют его сами - вопрос: какой ценой и формализовать рычаги воздействия(?) -- не все маркетологи понимают какие и какой ценой... некоторые даже забывают вспомнить о спросе
7) а вот по входным данным - их, действительно, мало (поэтому и просчитываются быстро на среднем пк), но надо много (в реал бизнесе для прогноза, которому можно доверять)
8 ) -- и МНК не всегда "the best"... алгоритм поиска theta=dQ/dP по МНК даёт, вероятно, смещённые оценки по сравнению, например с DML - python notebook из этой статьи -- не вникала в алгоритм от Vladimir Ch и не тестила оба на реал данных - но во 2-м там есть шаг demeaning - вобщем, возможно, не все кривые одинаково хорошо аппроксимируются по МНК  --  а, может, просто работа с шумом, а не с центральной тенденцией, - даёт более точное сглаживание, чем МНК...
9) а по-хорошему - сначала надо тест Дики-Фулера сделать на стационарность данных, и если они стац., то можно выделять тренд, цикличность и остатки (если в них просматривается паттерн - то либо заменить модель, либо период) и в любом случае (!)Оптимизировать на параметры сглаживания , чтобы чтобы выявить цикличность... или делать pmdarima.auto_arima... расписывать дерево на выбор лучших параметров вручную на DAX - не "comme ils faut"  и не удобно
10) прежде не забыв поубирать праздники и др выбросы ... чтобы улучшить качество модели, уменьшив ошибку - e.g. как здесь
p.s.
по python ничего не приложу для сравнения удобств в моделировании, - слетела pandas_lib...  да и нет смысла здесь кодить на др. яз,... просто для инфо

Computational Statistics in Python - если решите делать это на более подходящем языке -  для оптимизационных задач, которые в изобилии будут встречаться в стат.анализе...  хотя  чисто для оптимизации вероятностных систем (на min/max) и Пакет Анализа из Excel - даёт решение, но не марковсих -  в очередной раз соглашусь с Vladimir Ch про рекурсию...
(не видела  решений в Excel, кроме надстроек - например RealStatistics)...

в общем:
сглаживание (smoothing)
прогноз (SARIMAX Model)
-- разработана очень большая library statsmodels в Python для оценки АвтоРегрессионных моделей и др
== сделать авторегрессию ручками в DAX - проблематично - можно только порисовать графики (подготовить данные для АР-модели сложно - нет соотв. объектной модели, т.к. DAX лишь функциональный язык, не более того)...

его может вызвать только доверительный интервал (CI)
P.S.
Нестационарный процесс можно прогнозировать только на 1 шаг вперёд,  - "потому что будущее состояние зависит только от текущего" -  более длинный горизонт и вероятности иных состояний будут известны только по факту, но не сейчас apriori, поэтому прогноз более долгосрочный теряет смысл и уровень доверия...  т.к. добавляется количество неопределённости (например, данных завтра и послезавтра для прогноза на после-после-завтра)- возможно, вариант: просчитать прогноз на шаг вперёд для усреднённых/сглаженных часовых отдельно и усреднённых/сглаженных дневных отдельно... и смотреть однонаправленность прогноза. - подтверждают ли др др... но в любом случае: такой прогноз лишь отражает выводы на основе сглаженной истории... для более реального прогноза лучше см. настоящий state и его латентные факторы(признаки) - если процесс Марковский ! если нет - то пока не встречала формализованных способов работы с неопределённостью (стохастической и уж тем более нестохастической - её вообще сложно формализовать в какую-либо аналитическую функцию)... поэтому смотрят стохастические решения и разрабатывают эвристические методы поиска решения (генетические алгоритмы, нейросети и др) - если задача стохастическая, или приводят её к детерминированному виду...
P.P.S.
прогнозировать неопределённость (когда это возможно) можно только с доверительными интервалами...
но нет смысла переносить историю в будущее, если процесс вероятностный и даже нет детерминированного тренда, в лучшем случае - лишь стохастический тренд... если тренд вообще есть, а не сглаженная история... - см. лучше текущий state ...
P.P.P.S.
и для немарковских процессов надо (!!) иметь все условные вероятности -- для этого провести все эксперименты по conditioning, что невозможно в соц-эк явлениях, только statistical inference --> оценки всегда смещённые, т.к. почти всегда существуют случаи out-of-sample и/или малые выборки (не дающие статистически-устойчивых результатов) ...

#3 столбец Сезонный прирост, % -- логика расчётов не соответствует своему названию  
надо см автокорреляцию для выявления Сезонных циклов - пример Python для выявления дневной цикличности и соглашусь с цитатой (даже не про рекурсию [но про неё тоже], а про удобство/скорость выполнения оптимизационного запроса в DAX, циклом можно пройти быстрее, вероятно, в др яз)
хоть и есть расхождения в ф-ции autocorr и autocorrelation_plot в Python...
но суть поиска цикличности в том, чтобы # Calculate the estimate for a set of different chain lengths - т.е. для разл лагов и см. min error с реал данными,

p.s.
sorry за пример из др яз, но если это реализовать на функциональном DAX - то только тогда сможете отразить Сезонные циклы - потому что сезонность рассчитывается именно из автокорреляции (и  для  данных из разной длины диапазона, чтобы словить high-frequency циклы и low-frequency циклы путём сглаживания сигнала , и последовательно тестируя разные лаги) выделить max правдоподобие... из этого алгоритма только max удобно делать на функциональном языке...
по алгоритму тоже были дебаты например в emcee library и вариант(ы) реализации. потому что в принципе... поэтому тоже с алгоритмом в целом ещё определяться и определяться, не говоря уже об исполнении и выборе языка для исполнения... не знаю, есть ли в DAX функции для расчётов сезонных циклов, но делать это ручками явно не стоит в DAX, как наверно, и в Excel...
ЧТОБЫ ОЧИСТИТЬ РЕАЛ ПРИРОСТ ОТ СЕЗОННОЙ СОСТАВЛЯЮЩЕЙ

по линку #2 у вас такое и отражено, только на одном графике - данные от модели линией тренда, и данные файла реал данных - линией ломаной ...  

вы ей льстите... или вашим данным...

как обычно:
один отдел работает, второй ждёт первого, потом наоборот ... а платить придётся 1+1=2... расход человеко-времени 2x, полезность - лишь 50% ... вы правы: вопрос рентабельности - уже не ваш вопрос

LS (МНК) - Итог: mean+/-3sigma - for Normal data - н привести к Normal
MLE under Gaussian Noise (no Autocorr) - Итог: best with AIC - for Non parametric data ()

реал данные ненормальны, а TS имеют автокорреляцию - поэтому надо правильно ставить вопрос и брать правильные (Random Values!) данные (для независимости опытов), чтобы стат. выводы помогали... при том что "Statistics can’t be used to variable data"  - начинает работать, только если есть закономерность, вскрытие которой и есть задача Structural Engineering... чтобы выделять реальные тренды из latent-space, а не фиксить по факту результат незамеченных/невскрытых предпосылок

вывод LS: mean+/-3sigma это вывод для норм data
вывод max-likelihood это вывод для non-parametric data (нет mean, нет sigma - но можно найти MaxLikelihood) - обычно данные именно такие

для последнего м исп разл optimization algos:
- quadratic algo - in SVM (Euclidead distance) -- NB выбрать правильный Kernel (это фильтр) для имеющегося use-case
- Gradient Descent - in Neural Networks  -- NB if it can  converge
(т.е. чтобы был толк от более сложных вычислений [оптимизации на макс/мин] - задачу в любом случае надо сводить к квадратичному виду! чтобы нашёлся этот convergence point условно говоря, т.е. min [от negative log-likelihood] или max[от log-likelihood], т.е. решение)

и остаётся вопрос Интерпретации результатов:
для Непараметрических моделей (часто по реал данным м построить т их) - LIME  (или здесь)... - независимо от модели... - генерится куча однотипных (по своей схеме) данных и ищется наиболее подходящий - по сути всё тот же Monte-Carlo Markov Chain алгоритм - мне так кажется... (хоть никто из так называемых "экспертов" - не может по алгоритму и тому и др (LIME и MCMC и NN) объяснить, в чём отличие, или ?? как обычно отличие в том "кто как что" обозвал)

p.s.
и да, вы правы - важна постаноВка вопроса - для любых оптимизационных задач (хоть по МНК, хоть по MLE) важно, чтобы задача/решение (или область решений) имела сходимость (т.е. решение на поиск нужного), т.е. can converge to min/max...
возможно вы хотите, чтобы вам всегда предоставляли алгоритм, а вы выполняли только техническую составляющую ТехЗадания,
но зачастую заказчик считает, что если у вас проф.тех.(высшее) образование - то вы сами можете состряпать алгоритм - хоть по Лапласу из ~ 18-го века, хоть по Лагранжу, хоть свой собственный - и именно вы должны выбрать/предложить максимально быстрый и дающий точные результаты алгоритм (как технарь), потому что вас этому учили, а не заказчика... но заказчик не хочет терять деньги () потому что вы выбрали не тот алгоритм == для этого вам надо знать все Assumptions ваших моделей, которые технически реализовываете (или иметь/найти экспертное мнение - e.g. статиста, но не руководителя бизнеса - это не его проблемы)...
т.е. программист со своими статистами(экспертами) - тоже имеет больше шансов реализовать адекватную модель (ту, на которую можно полагаться, а не просто отдавать на суд потребителя ТУИ предприятия, используя для рекламных графиков, -- ни потребитель, ни заёмщик денег на бизнес не обязаны разбираться, почему вы выбрали Ньютона или Лагранжа, ни даже статист (эксперт), - вы должны уметь объяснить (где OLS [МНК], а где MLE и почему вы выбрали один vs. др.) ... вы, как технарь... сбросить ответственность того, что и как вы считаете, на кого-либо не получится -- это ваша компетенция -- и да, к знаниям надо прилагать опыт работы с данными и задачами такого типа, работы с пониманием "какие расчёты к каким данным", а не надеждой, что поймёт кто-то вместо вас... поэтому часто "компьютерщики" и заказчики не могут услышать друг друга, когда между ними нет связующего звена - экспертов того, в чём один не должен разбираться, а второй имеет нехватку инфо для своего ТЗ... - а "эксперты" генерят не логику, а новые слова , не в состоянии сгенерить адекватное решение, и коверкают язык, продвигая свои новые слова (названия алго) под новым брендом, имеющим однако всё те же старые добрые ньютоновсие алгоритмы, НО без объяснения, как они их применили, обозвав новым словом, -- что и вызывает сомнения "а поняли ли сами, что обозвали" -- язык теряет силу для выстраивания конструктивного диалога, превращаясь в кувалду, когда отказываются от языка "знаний из опыта" (даже исторического) в пользу языка "я придумал, чтобы обозвать и продвигать" -- но любое "придумал" имеет под собой базу - важно, чтобы она не была гнилой... background считающего и становится базой в расчётах... это как в марковских моделях: всю историю м включить фактором в текущий state ... - каков текущий state, такие и расчёты - по Байесу...
====

поэтому так и получается: "надо чтобы прогноз был"... когда в фирме нет ни экспертов, ни квалифицированных (от слова "знания+опыт", а не слова "корочка") математиков (applied math) -- такие и прогнозы... а опыт, действительно, нарабатывается только на работе, а не из алгоритма псевдослучайных чисел -- в жизни же не всё случайно... и опыт передаётся по истории в текущее состояние (как в MCMC), а не как "я придумал брэнд" (что-то туда вложил, не знаю что, - просто поработал с shaker'ом, внедрив последние технологии работы барменов в отрасль прогнозирования) -- "так вы брэнд-менеджер или вы программист или вы бармэн или что-то помните из того, чему вас учили?" [примерный риторический скрытый вопрос на собеседовании]

они же не выдаются... или вы можете показать КАК? - я вот и хотела бы, что выскочил Диалог
могу не заметить - фокус внимания на этапе работы PQ явно не на PQ (т.к. запрос долго отрабатывает с большим объёмом данных)... хочется автоматического уведомления... но в тему приложу ваше предложение - "Панель запросов" появляется на событие Worksheet_Activate () -- событие можно заменить, но не в этом суть, - отразила визуализацию эффекта -  ...
Если кто сможет выбросить MsgBox при error в запросе - тестовый PQ_запрос прилагается

Скрытый текст

Код let     Источник = Excel.CurrentWorkbook(){[Name="Таблица1"]}[Content],     #"Измененный тип" = Table.TransformColumnTypes(Источник,{{"Столбец1", Int64.Type}, {"Столбец2", type text}}),     #"Добавлен" Table.AddColumn(#"Измененный тип", "dt", each Text.From( Date.From(DateTime.LocalNow ()),  "en-US")),     udf= (x as text) as text => let            step1= if x="ол" then error"Business Rule Violated!" else x          in step1,     #"Added Custom" = Table.AddColumn(#"Добавлен", "Exceptions", each  udf(_[Столбец2])) in     #"Added Custom"

то Добро пожаловать на ветку...
в любом случае: Всех с 1-м мая)  

Жаль, но спасибо за оперативный ответ.
А было бы удобнее выбросить msgbox'ом инфо из боковой панель Данные -> Показать запросы (даже без детализации ошибок) - факт наличия ошибок. (придётся городить errorQueries на досуге)