В конфигурации «1С:Управление торговлей 11.1» пользователи часто сталкиваются с ситуацией, когда классическая цепочка обеспечения «Заказ клиента — Заказ поставщику — Поступление товаров» работает идеально до того момента, пока не возникает необходимость переместить этот товар на другой склад. Если товар поступил под конкретное Назначение (обособленное обеспечение), попытка оформить документ Перемещение товаров часто заканчивается ошибкой контроля остатков. Система сообщает, что товара недостаточно, хотя фактически он числится на складе.
В этой статье мы подробно разберем, почему так происходит, как устроена механика обособленного учета в версии 11.1 и какие существуют способы решения этой проблемы — от методологических до программных.
Проанализируем ситуацию с точки зрения регистров. В УТ 11.1 за учет товаров отвечают несколько ключевых регистров накопления. Когда товар поступает на склад под назначение (например, под конкретный заказ клиента), запись в регистре Товары организаций создается с заполненным измерением Назначение.
Основная сложность заключается в том, что в ранних релизах УТ 11.1 логика документа Перемещение товаров при проведении проверяет наличие свободного остатка. Свободный остаток — это товар, у которого измерение Назначение не заполнено (пустое). Поскольку ваш товар жестко привязан к заказу, он не является «свободным», и типовой запрос контроля остатков его «пропускает», выдавая ошибку о нехватке.
Кроме того, при вводе Перемещения товаров на основании Поступления товаров и услуг программный код конфигурации может некорректно заполнять (или вообще не заполнять) колонку Назначение в табличной части перемещения. В итоге получается замкнутый круг: вы пытаетесь переместить «пустой» товар, которого нет, вместо «обособленного» товара, который есть.
Если мы не хотим вносить изменения в программный код, рассмотрим наиболее правильный с точки зрения типовой методологии путь. Нам необходимо временно «освободить» товар от назначения на Складе А, переместить его как свободный остаток и снова «закрепить» за заказом на Складе Б.
Этот способ надежен, так как сохраняет чистоту партионного учета и корректность движений по регистру Запасы и потребности, однако он трудозатратен для менеджеров, если перемещения происходят часто. При необходимости можно воспользоваться инструментом для массового изменения и снятия резервов в заказах.
Если мы проанализируем модуль объекта документа Перемещение товаров, а именно процедуру ОбработкаЗаполнения, мы увидим, что при копировании данных из документа-основания (Поступления) поле Назначение может игнорироваться. Чтобы упростить жизнь пользователям, мы можем внести изменения, чтобы назначение переносилось автоматически. Для этой задачи также подойдёт готовое расширение для создания документов перемещения товаров напрямую из заказа покупателя.
Рассмотрим пример кода, который можно внедрить в процедуру заполнения на основании:
// В процедуре ОбработкаЗаполнения документа ПеремещениеТоваров
Если ТипЗнч(ДанныеЗаполнения) = Тип("ДокументСсылка.ПоступлениеТоваровУслуг") Тогда
Для Каждого СтрокаИзОснования Из ДанныеЗаполнения.Товары Цикл
НоваяСтрока = Товары.Добавить();
ЗаполнитьЗначенияСвойств(НоваяСтрока, СтрокаИзОснования);
// Принудительно заполняем Назначение, если оно есть в поступлении
Если ЗначениеЗаполнено(СтрокаИзОснования.Назначение) Тогда
НоваяСтрока.Назначение = СтрокаИзОснования.Назначение;
КонецЕсли;
КонецЦикла;
КонецЕсли;
Важный нюанс: Просто заполнить колонку в документе мало. В УТ 11.1 часто требуется, чтобы в самом документе была включена видимость колонки Назначение. Если она скрыта программно или через настройки формы, механизм проведения может её игнорировать. Убедитесь, что в форме документа Перемещение товаров через «Изменить форму» поле Назначение доступно и отображается.
Самый сложный, но эффективный путь — выясним причину блокировки проведения в коде. В УТ 11.1 контроль остатков часто завязан на функцию СформироватьЗапросКонтроляОстатков. Проблема кроется в том, что запрос ищет совпадение по всем измерениям регистра ТоварыОрганизаций.
Если в документе перемещения указано Назначение, система делает запрос к регистру с этим фильтром. Если проведение все равно не проходит, проверим, не «разваливается» ли остаток по сериям или складам. Посмотрим на пример того, как система проверяет остатки в регистре ТоварыОрганизаций:
Запрос.Текст =
"ВЫБРАТЬ
| ТоварыОрганизацийОстатки.КоличествоОстаток КАК Остаток,
| ТоварыОрганизацийОстатки.Назначение КАК Назначение
|ИЗ
| РегистрНакопления.ТоварыОрганизаций.Остатки(&Период, Организация = &Организация
| И Склад = &Склад
| И Номенклатура = &Номенклатура
| И Назначение = &Назначение) КАК ТоварыОрганизацийОстатки";
Если в вашем документе Перемещение товаров назначение заполнено верно, а ошибка все равно возникает, скорее всего, дело в складе в Заказе клиента. В УТ 11.1 обособление жестко привязано к складу, указанному в заказе. Если в Заказе клиента указан «Склад А», а вы перемещаете товар на «Склад Б», для системы это назначение на новом складе становится невалидным, так как оно «ждет» товар на складе А.
В этом случае решением будет либо смена склада в самом Заказе клиента перед перемещением (что может быть невозможно, если часть товара остается на первом складе), либо использование схемы с корректировкой назначений, описанной выше.
Проанализируем ситуацию: почему в более поздних версиях 1С эта проблема встречается реже? В новых редакциях появилась настройка «Разрешить обособление товаров и работ сверх потребности» и более гибкая система управления резервами. В УТ 11.1 логика более жесткая: назначение — это не просто «метка», это полноценное измерение учета, которое нельзя игнорировать ни в одной складской операции.
Подведем итоги:
Назначение в табличной части документа перемещения.Заказе клиента (назначении).Корректировка назначений для «перекидывания» резерва между складами.ОбработкиЗаполнения, чтобы менеджеры не вводили назначение вручную при создании перемещения на основании поступления.Помните, что архитектура УТ 11.1 требует строгого соблюдения последовательности: сначала обеспечение потребности, затем перемещение под эту потребность. Нарушение этой логики всегда приводит к ошибкам контроля остатков.