Прогноз плюс заказы: какую потребность действительно включать в план

Сначала выясните смысл исходного прогноза

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

Первое решение — означает ли прогноз полный ожидаемый спрос или только дополнительный спрос сверх уже известных заказов. Для полного прогноза нужна проверка пересечения. Если аналитик заранее исключил заказы и передал только ожидаемый дополнительный спрос, повторное поглощение занизит план. Название поля «прогноз» не разрешает эту неоднозначность.

Microsoft Business Central также различает виды прогноза и подходящую потребность: продажи и зависимый спрос компонентов обрабатываются по разным правилам. Это пример того, почему нельзя уменьшать любой прогноз любой найденной строкой. Microsoft: Create a demand forecast.

Далее выбрана собственная прозрачная модель полного спроса одного SKU в одной точке. Это не инструкция для всех ERP и не обещание одинакового алгоритма в разных конфигурациях.

Определите подходящие заказы и границы периода

До расчёта зафиксируйте товар, вариант, единицу, место исполнения и коммерческий охват прогноза. Общий прогноз всех каналов и отдельный прогноз одного клиента могут пересекаться. В иерархической модели один заказ может корректно уменьшать несколько связанных записей. Microsoft отдельно описывает уменьшение клиентского и общего прогноза при снабжении только общего количества. Контроль нужен на уровне итогового плана: пересекающийся спрос включается в него один раз по объявленной иерархии. Далее рассматривается плоская модель одного SKU, точки и периода, без такой иерархии. Microsoft: клиентский и общий прогноз.

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

Укажите подходящие статусы. В учебной модели используются только подтверждённые клиентские строки, включённые в тот же охват спроса. Черновики и отменённые количества исключены. Не переносите эту политику автоматически на свой процесс: набор документов и момент их участия должны быть согласованы.

В документации Planning Optimization методы уменьшения прогноза и применимость транзакций определены отдельно. Ниже используется правило непересекающихся периодов без переноса поглощения между ними; оно не объявляется универсальным поведением Microsoft. Microsoft: Planning Optimization и прогноз.

Учебный пример: две будущие недели

Все числа вымышлены, время — UTC. Расчёт выполняется 9 октября, когда оба периода ещё впереди:

• P1: с 12 октября 00:00 включительно до 19 октября 00:00, не включая эту границу;
• P2: с 19 октября 00:00 включительно до 26 октября 00:00, не включая эту границу.

Исходный полный прогноз — по 100 штук на период. Подтверждённый заказ A требует 60 в P1. Заказы B и C требуют соответственно 90 и 40 в P2. Итого заказано 190: 60 в первом периоде и 130 во втором.

Никакие складские остатки пока не вычитаются. Мы сначала формируем потребность, а не рассчитываем закупку или доступность товара. Пригодное наличие и поступления будут сопоставлены с ней отдельным шагом.

Посчитайте остаток и совокупную потребность

Для каждого периода обозначим полный прогноз F, подходящие заказы O. Поглощённая часть равна меньшему из F и O. Оставшийся прогноз равен максимуму из нуля и F − O. Совокупная плановая потребность — заказы плюс оставшийся прогноз.

Для P1: поглощено 60, осталось 100 − 60 = 40. Общая потребность равна 60 + 40 = 100.

Для P2: поглощено 100, остаток прогноза равен нулю. Заказы не уменьшаются до прогноза: все 130 продолжают требовать исполнения. Общая потребность — 130.

Итог двух периодов: 100 + 130 = 230. Простая сумма исходного прогноза 200 и заказов 190 дала бы 390. Завышение составляет 160, то есть именно повторно учтённую поглощённую часть: 60 + 100.

У 30 единиц заказов сверх второго прогноза нет автоматического права уменьшить первый период. В выбранной политике они не относятся к нему. Описанный в текущей документации Microsoft dynamic-period метод также не переносит превышение в следующий период; конкретные методы и окна следует проверять отдельно. Microsoft: методы forecast reduction.

Один перенос даты меняет результат

Теперь отдельное подтверждённое изменение: заказ C на 40 единиц перенесён из P2 в P1. Его требуемая дата стала 18 октября. Количество всех заказов по-прежнему 190; исходный прогноз остаётся 100/100.

Новое распределение заказов — 100 в P1 и 90 в P2. Остаточный прогноз теперь 0 и 10. Совокупная потребность равна 100 + 90 + 10 = 200.

Снижение расчётного плана с 230 до 200 не означает отмену 30 реальных заказанных единиц и не доказывает экономию денег. Изменилось пересечение заказов с ожидаемым спросом по двум периодам. Чтобы этот вывод имел смысл, прогноз должен действительно описывать тот же временной и коммерческий охват.

Сохраните прежний расчёт, изменение даты C и новую версию. Если уже размещена закупка под старые 230, результат пересчёта сам по себе не отменяет её. Планировщик отдельно проверяет действующие обязательства и допустимое изменение поставки.

Исходный прогноз не должен исчезнуть

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

Для проверки можно вести связь по строкам. В исходном сценарии A поглощает 60 в P1. Если в P2 сначала обрабатывается B, он поглощает 90; C поглощает оставшиеся десять, а ещё 30 входят как превышение. Другой порядок строк не меняет общий остаток при одинаковой применимости, но меняет связи, поэтому порядок должен быть воспроизводимым.

При завершении или частичном исполнении заказа нельзя молча терять его роль в потреблении прогноза. Документация Planning Optimization отдельно оговаривает участие обработанных заказов и соответствующие настройки. Для своего процесса проверьте, какие события и количества продолжают учитываться; остаток открытого исполнения и объём поглощения могут отвечать на разные вопросы.

Данные, ошибки и приёмочные проверки

Сохраните версию прогноза, его смысл и охват, границы периода, дату среза, подходящие строки заказов, использованную дату спроса, поглощённое количество и причину исключения. Для пересчёта нужны история изменения даты, отмены и применённая версия правил.

Частые ошибки — поглощение по дате создания, смешение точек, повтор одной строки из нескольких каналов, перенос излишка между периодами без правила и вычитание заказов из уже очищенного дополнительного прогноза. Любая из них может дать аккуратный итог с неверным смыслом.

Проверьте процесс на следующих случаях:

• исходные остатки 40/0 дают совокупные 230, а не 390;
• после переноса C остатки 0/10 дают 200 при прежних 190 заказанных;
• заказ с датой ровно 19 октября попадает только в P2;
• заказ другой точки не поглощает неподходящий прогноз;
• одна строка не уменьшает прогноз повторно при повторной загрузке;
• отмена и изменение даты выпускают воспроизводимый пересчёт;
• исходные 100/100 сохраняются для анализа качества;
• предложенный план не считается размещённой закупкой.

В производстве, закупках и складе SABSUS подтвердите необходимые связи и поведение конфигурации. Наличие прогноза или заказов само по себе не доказывает готовую функцию forecast consumption. Этот расчёт дополняет процесс производственного планирования.

Частые вопросы

Нужно вычитать все заказы из любого прогноза?

Нет. Сначала установите, включает ли прогноз эти заказы и совпадают ли товар, точка, период и охват.

Заказ сверх прогноза нужно сократить?

Нет. В примере все 130 единиц второго периода остаются обязательством; остаточный прогноз лишь становится нулевым.

Поглощение улучшает точность исходного прогноза?

Оно устраняет пересечение плановых источников. Точность оценивается отдельно по сохранённому прогнозу и сопоставимому факту.

Источники

• Microsoft Learn: Create a demand forecast.
• Microsoft Learn: Planning Optimization with demand forecasts.

Проверено 9 октября 2026 года. Политика периодов и числовые сценарии учебные.