При управлении складскими запасами в 1С:Управление торговлей (редакция 11) часто возникает задача обеспечения потребностей по группе аналогичных товаров. Классический пример: на складе присутствует один и тот же товар от разных производителей (например, молоко 1л от брендов «Белая коровка», «Черная коровка» и «Пятнистая коровка»). Перед снабженцем стоит задача поддерживать на складе суммарный страховой запас молока в объеме 500 литров, независимо от того, какой именно производитель сейчас находится на остатках.
Если настроить стандартное поддержание запасов для каждой карточки номенклатуры отдельно, то при падении остатков система попытается заказать каждый товар до установленного минимума. Например, если у нас осталось 120 л «Белой коровки», 40 л «Черной коровки» и 80 л «Пятнистой коровки» (суммарно 240 л), стандартный расчет потребует дозаказать каждую позицию до своего индивидуального лимита. Нам же необходимо, чтобы система сложила остатки всех трех производителей (120 + 40 + 80 = 240 л), вычла этот объем из совокупного страхового запаса (500 л) и сформировала заказ поставщику на разницу — 260 л по одной из выбранных позиций (например, по наиболее приоритетной).
Давайте подробно разберем, почему стандартный механизм обеспечения потребностей накладывает такие ограничения, и рассмотрим четыре практических варианта решения этой задачи.
Для начала проанализируем архитектуру подсистемы обеспечения потребностей в программах 1С:Управление торговлей 11, 1С:Комплексная автоматизация 2 и 1С:ERP. Вся логика расчета дефицита и формирования заказов базируется на регистре накопления ЗапасыИПотребности. Расчет выполняется строго в разрезе ключевых измерений:
В типовом функционале программы не предусмотрена агрегация остатков разных номенклатурных позиций (даже если они связаны через справочник «Аналоги» или объединены общим дополнительным реквизитом/свойством) для сравнения с единым минимальным запасом. Алгоритм всегда анализирует каждую карточку номенклатуры обособленно. Ниже приведены проверенные способы обойти это ограничение.
Если для вашего бизнеса и конечных покупателей молоко разных производителей абсолютно идентично (оно продается по одной цене, под одним штрихкодом и клиенту не важно, продукцию какого завода ему отгрузят), наиболее правильным решением будет объединение позиций в одну карточку номенклатуры.
Чтобы при этом сохранить возможность заказывать товар у разных поставщиков под их собственными наименованиями, выполним следующие настройки по шагам:
Молоко 1л (общий учет).Молоко 1л (общий учет) на нужном складе со значением минимального запаса в 500 л.Как это будет работать при формировании заказа:
На складе будет числиться единый остаток (240 л). Система увидит совокупную потребность в 260 л. При запуске обработки «Формирование заказов по потребностям» программа предложит заказать 260 л единого молока. В момент создания документа Заказ поставщику, при выборе конкретного контрагента, система автоматически подставит в печатную форму его индивидуальное наименование товара («Белая коровка» или др.), основываясь на регистре сопоставления. Таким образом, складской учет останется простым и понятным, а закупки будут оформлены корректно.
Часто пользователи пытаются решить задачу через ведение учета по одной карточке номенклатуры Молоко 1л, где в качестве характеристик выступают производители («Белая коровка», «Черная коровка» и т.д.). Рассмотрим подробнее, почему этот вариант не решает задачу совокупного обеспечения в полной мере:
Поэтому стандартный механизм характеристик без дополнительных доработок запросов расчета потребностей для решения нашей задачи не подходит.
Если в вашей системе принципиально важно вести учет молока разных производителей на разных карточках номенклатуры (например, у них разные штрихкоды, разные розничные цены, или этого требуют правила ведения партионного учета подконтрольной продукции во ФГИС «Меркурий» / «Честный Знак»), задачу можно решить путем создания небольшого расширения конфигурации.
Разберем логику работы такого расширения:
ГруппаАналоговДляЗакупок (тип: Справочник «Дополнительные значения» или текстовое поле).ОсновнойАналогДляЗаказа = Истина. Именно на нее будет оформляться вся совокупная потребность к заказу.ФормированиеЗаказовПоПотребностям (модуль менеджера или специализированный класс расчета потребностей в зависимости от версии УТ). Нам необходимо скорректировать запрос получения текущих остатков.Проанализируем примерный алгоритм модификации запроса на встроенном языке 1С:
// В расширении перехватываем таблицу рассчитанных потребностей перед выводом в форму
Процедура ПередРасчетомПотребностей(ТаблицаДанных)
// Шаг 1. Группируем текущие остатки по нашему дополнительному реквизиту аналогов
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| Номенклатура.ДополнительныйРеквизитГруппаАналогов КАК ГруппаАналогов,
| СУММА(ЕСТЬNULL(СвободныйОстаток, 0)) КАК ОбщийОстаток
|ИЗ
| РегистрНакопления.ЗапасыИПотребности КАК Запасы
|ГДЕ
| Номенклатура.ДополнительныйРеквизитГруппаАналогов <> ЗНАЧЕНИЕ(Справочник.ДополнительныеЗначения.ПустаяСсылка)
|СГРУППИРОВАТЬ ПО
| Номенклатура.ДополнительныйРеквизитГруппаАналогов";
// Шаг 2. Корректируем строки таблицы потребностей
// Для основного аналога в группе устанавливаем остаток равный "ОбщийОстаток"
// Для неосновных аналогов временно исключаем потребность, чтобы избежать дублирования закупки
КонецПроцедуры
Благодаря этой доработке система сложит остатки 120 + 40 + 80 = 240 л, сопоставит их с лимитом основной номенклатуры (500 л) и выдаст к заказу ровно 260 л «Молока 1л белая коровка», проигнорировав необходимость заказа по остальным позициям-аналогам.
Если вы не хотите вносить изменения в код программы и создавать собственные расширения, можно использовать готовые коммерческие модули управления запасами для 1С (например, специализированные помощники автозакупок, внешние обработки типа «Мегапрайс» или профессиональные подсистемы прогнозирования запасов).
В таких решениях функционал работы с аналогами реализован на высоком уровне:
Выбор конкретного варианта зависит от масштаба вашего предприятия, требований к детализации складского учета и готовности к доработке типовой конфигурации 1С.