Листы: InventoryInput, детализация OpenPO, Parameters, ReorderReview, Exceptions, ApprovalLog и Reconciliation. Храните расчётное предложение отдельно от BuyerDecision, ApprovedQty, PONumber и ApprovedAt.
Для Filter-F9 Available=42−8−2=32. Подтверждённый заказ на закупку с поставкой 8 сентября входит в двухнедельный горизонт, заканчивающийся 15 сентября, поэтому InventoryPosition=32+24=56. LeadDemand=15×2=30; ReorderPoint=30+12=42; Target по умолчанию=30+12+15=57. Поскольку 56 не меньше 42, статус — «Не заказывать», хотя запас на одну единицу ниже целевого: политика запускает действие при достижении точки повторного заказа, а не целевого уровня.
Формулы таблицы: Available =[@OnHand]-[@Reserved]-[@Damaged]; EligibleOpenPO следует суммировать по детализации заказов на закупку с условиями по статусу и дате поставки, а не полагаться на одно агрегированное значение при наличии нескольких заказов; InventoryPosition=Available+EligibleOpenPO; LeadDemand=AvgWeeklyDemand*LeadTimeWeeks; ReorderPoint=LeadDemand+SafetyStock. При срабатывании RawNeed=MAX(0,Target-InventoryPosition). Для округлённого предложения можно использовать =MAX([@MOQ],CEILING.MATH([@RawNeed],[@PackSize])), но только после проверки положительных значений PackSize и MOQ.
Приоритет оповещений: дубликат, отсутствие обязательного поля, неверный тип или устаревшие данные → проблема с данными; Available<0 → дефицит или ошибка учёта; просроченный или неподтверждённый заказ на закупку, влияющий на горизонт, → проверить поставку; позиция ниже точки повторного заказа → проверить повторный заказ; иначе → не заказывать. Условное форматирование основывается на тексте статуса, а не на одной лишь вложенной логике цветов. Тесты включают позицию 35, дающую RawNeed 22 и предложение 24; округление RawNeed 25 до 30; нулевой спрос, дающий по политике статус «Не заказывать»; исключение и пометку заказа на закупку, который поступает на день позже горизонта; блокировку предложения при отсутствии поставщика или обновлении восьмидневной давности; применение переопределения только при наличии целевого значения, причины, проверяющего и даты. При каждом обновлении сверяйте количество строк и сумму OnHand с источником, а включённые и исключённые количества OpenPO — с реестром заказов на закупку.