Почему расчёт потребностей в запасах в 1С:УНФ считает не то, что нужно цеху

Проблема, естественно, не в том, что программа «врёт». Обработка считает ровно так, как положено, она не глючит как искусственный интеллект. Берёт заказ покупателя, спецификацию и уровни запаса из карточки номенклатуры и складывает из этого свою модель обеспечения. Но дело в том, что всего этого недостаточно.

Разберём, из каких документов складывается потребность, чем обработка потребностей отличается от одноимённого отчёта и от минимума и максимума запасов, когда типовой УНФ хватает, а когда нужно доработать (и программу, и расчёты).

Первая путаница начинается ещё до кнопки «Рассчитать». В мире УНФ под термином «потребность» живут три разных инструмента. Если не разобраться, то можно уйти не туда, правда, иногда бывает так, что другие эксперты тоже не разбираются или сознательно путают читателей… если запутаетесь — приходите к нам на консультацию, за полчаса распутаемся.

• Обработка «Расчёт потребностей в запасах». С её помощью можно рассчитать и получить ответы «что закупить», «сколько дефицит, и что и сколько закупить, чтобы закрыть „дыру“».
• Отчёт «Потребность в запасах». Просто показывает картинку «сколько нужно», «сколько есть» и «сколько заказано».
• Уровни минимума и максимума в запасами». По сути это лампочка, которая сигнализирует «что-то не так». Когда материалов слишком мало — надо закупить, если слишком много, значит или работаем медленнее и поставок больше, чем расход или производим больше, чем успеваем произвести. Ведь готовая продукция тоже может быть запасом!

На первый взгляд разница не критичная, и в обзорах эти термины часто используют как взаимозаменяемые. Я душнить пока не буду, но дальше буду писать «обработка» — подразумевая именно инструмент с кнопкой «Сформировать заказы», а «отчёт» — итоговую картину.

Прежде чем считать, обработку нужно включить в настройках: «Ещё больше возможностей», раздел «Закупки», подраздел «Планирование», «Расчёт потребностей».

Дальше всё зависит от того, из каких документов взята потребность.

У обработки два способа расчёта: по заказам и по продажам. По продажам она берёт средний расход и уровни минимума и максимума, а потом дополняет запас до максимума. Для торговли с полки так и надо. Цеху со спецификацией и датой отгрузки — нет: средний расход за прошлый месяц не подскажет, какие материалы нужны под конкретный заказ и к какому числу.

Расчёт по заказам устроен не так, как читается по названию. Типовая УНФ берёт данные из заказа покупателя, даже если материалы уже расписаны в заказе на производство. Мастер работает по цеховому документу, если вообще заходит в 1С, а обработка считает по заказу покупателя. Отсюда первое расхождение в цифрах.

Спецификация в расчёт идёт не любая, а основная. Если у изделия несколько вариантов сборки, а основной отмечена не та, в потребность уедет чужая комплектация. Правильная останется только в заказе, который завели руками. `[проверить в базе 3.0]`

Наконец, способ пополнения обработка берёт прямо из карточки. Полуфабрикат, у которого не заполнена спецификация, а способ пополнения стоит «Закупка», уедет в заказ поставщику как покупной материал. И поставщик на тысячах позиций сам из приходных накладных не подтянется: кто не заполнил источник в карточке, тот потом правит каждую строку руками на стадии планирования.

👉 Кнопка «Рассчитать» не наведёт порядок в карточках. Если способ пополнения пустой, основная спецификация выбрана наугад, а заказы покупателей висят в статусе «КП отправлено», обработка аккуратно посчитает по этим кривым данным — и выдаст кривую цифру.

Непонимание этого момента чаще всего создаёт ситуации, из-за которых пользователи 1С думают, что «программа считает неправильно». А на деле в одном расчёте столкнулись две логики, которые не должны работать вместе. Контроль уровня запасов, который постоянно считает остатки запасов между минимальными и максимальными лимитами. И обеспечение заказа — расчитывает заказы, исходя из потребностей заказа.

Разберём пример. В карточке номенклатуры стоит минимальный остаток 10 и максимальный 20. Приходит заказ покупателя на 30 штук. Обработка предлагает не 30 и даже не «сколько не хватает под заказ», а пополнить склад до максимума — до 20. Снабженец «на опыте» берёт ровно столько, сколько советует программа. А там, если у компании сложные логистические цепочки и жёсткие дедлайны — могут быть проблемы.

Если в каком-то кафе в крупном городе, вдруг во время заранее запланированного банкета не хватило водки — можно сбегать в ближайший супермаркет и дозакупить. Скорее всего, это будет дороже, чем если бы закупали напрямую у поставщика, но проект не будет сорван. Впрочем, компании которая постоянно работает на «закрытые вечеринки», лучше перенастроить УНФ как раз на обеспечение. В ситуации с кафе — выход можно быстро и легко найти, даже если не получится быстро закупить нужные материалы — цена ошибки небольшая. А если это сложное производство со строгими обязательствами, импортные поставщики материалов и штрафами за срыв сроков?

Для финансиста — это, прежде всего, разговор про деньги, а не про механику. Он ориентируется на уровни минимума и максимума, чтобы контролировать оборачиваемость, когда на складе простаивает сырьё, потому что производство не успевает его обработать — это тоже плохо.

Мы иногда, такое встречаем в наших проектах стоматологии — материалы жутко дорогие и возникает желание «закупиться побольше», а там потом накладывается: сроки годности, поток клиентов, которым нужна услуга именно с этим расходником. А обеспечение складов строго под заказ, без страхового остатка, бьёт по срочным отгрузкам: каждую мелочь приходится «подтягивать» и работать в авральном режиме.

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

Обработка не проводит документы за вас. На стадии «Заказы» появляются черновики: заказы поставщику и на производство. В комментарии к такому заказу так и написано, что он сформирован автоматически сервисом расчёта потребностей. Их нужно открыть и проверить: поставщика, цену, склад и дату, и только потом провести.

Отдельная история — резервирование запасов. Без него часть обеспечения в УНФ не работает: в расчёт не попадает то, что уже занято под заказ, и в обработке не появляется расшифровка потребности по заказам. Включать резервы нужно, но аккуратно: неверный резерв потом мешает закрытию месяца. Спишете материал мимо резерва — программа начнёт ругаться, и разбираться придётся уже в конце месяца.

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

Для финансиста здесь важен не цвет колонки «дефицит», а то, сходятся ли между собой три числа: что в резерве, что свободно и что уже заказано, но ещё не отгружено. Пока они не сходятся, «Рассчитать» будет давать красивую, но недостоверную картину.

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

На коротком цикле и простой спецификации обработка отрабатывает нормально. Заказ на неделю, один-два уровня полуфабрикатов, один склад — этого достаточно, и городить методику незачем.

Проблемы начинаются на длинном заказе. Отчёт «Потребность в запасах» показывает материалы по заказу покупателя сразу на весь объём. Если изделие делается несколько месяцев, цеху на этой неделе нужна одна позиция, а снабжение видит потребность в материалах на всё изделие целиком. Поэтапно, «что нужно именно под текущую стадию», типовая не раскладывает.

Несколько переделов и складов усиливают тот же эффект. Классический случай: выпуск оформили на подразделение «Производство», а остатки материалов лежат на складе сырья. Обработка считает по «своему» складу, там пусто — и она снова предлагает пополнять то, что на деле уже произвели и передали дальше.

Ещё одна граница — работы. Материалы из калькуляции работы в заказе покупателя в потребность сами не попадают. Чтобы обработка их учла, нужен заказ на производство или спецификация на работу. Иначе цех спишет комплектующие, которых в расчёте не было.

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

Прежде чем нажимать «Сформировать заказы» на всю таблицу, стоит пройтись по короткому списку. Он закрывает большую часть случаев, когда «программа посчитала не то».

1. Какой инструмент открыт. Обработка, отчёт или карточка с уровнями минимума и максимума. Сравнивать их между собой бессмысленно: они отвечают на разные вопросы.
2. Способ расчёта. «По заказам» или «по продажам». Для производства под заказ «по продажам» почти всегда мимо
3. Фильтр пополнения. Если стоит «Закупка», а позиция производится, строк не будет — хотя дефицит на экране мастера реальный.
4. Основная спецификация и способ пополнения в карточке. Полуфабрикат не должен числиться покупным материалом без причины.
5. Уровни минимума и максимума. Если заказ больше максимума, обработка упрётся в потолок и предложит меньше, чем нужно под заказ.
6. Состояние заказа покупателя. Проведённое КП засоряет потребность лишними строками. Частичный возврат отгрузки иногда оставляет заказ «живым», и обработка снова просит закупить то, что уже вернули на склад.
7. Хвост после закрытия. Заказ покупателя закрыт, а в заказе на производство план больше факта списания — разница остаётся висеть в потребности. Сверять план и факт выпуска, а не только галочку «Завершён».
8. Склад и резерв. Свободный остаток лежит на другом складе, а фильтр стоит на один. Или всё в резерве под чужую сделку.
9. Черновик автозаказа. Поставщик, цена, дата поступления и связь с заказом покупателя. Провести заказ без этой проверки — значит утвердить чужую цифру своей подписью.

Снабженцу обработка экономит ручной обход заказов: показывает дефицит, подставляет поставщика из карточки и готовит черновик заказа. Но бухгалтеру и администратору базы она не заменит порядок в номенклатуре — на кривых карточках она такой же кривой и останется.

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

Собственнику и финдиректору важна не сама кнопка, а правило обеспечения. Пока его не сформулировали, УНФ считает то, что завели в карточки, и либо морозит деньги, дополняя склад до максимума, либо срывает срок, упираясь в тот же максимум.

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

Расчёт потребностей в запасах в 1С: УНФ не спорит с цехом из вредности. Он считает свою модель: заказ покупателя, основную спецификацию, способ пополнения из карточки, резервы и, если заданы, уровни минимума и максимума. У мастера перед глазами другое — текущий этап, свободный остаток и та спецификация, по которой идёт работа. Совпали эти две картины — обработка превращается в понятную очередь обеспечения. Не совпали — кнопка «Рассчитать» выдаёт аккуратную, но чужую цифру.

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

Если хотите разобрать, какая модель обеспечения нужна именно вам и где типовая УНФ перестаёт тянуть, — оставьте заявку на консультацию, напишите в телеграм @interlogik или позвоните +7 (495) 764 83 81.