Почему не заполняются ГТД и виды запасов при перемещении товаров в 1С:Управление торговлей 11.4?

При работе в программе «1С:Управление торговлей» версии 11.4 (а также в родственных конфигурациях «1С:ERP 2.4/2.5» и «1С:Комплексная автоматизация 2.4/2.5») пользователи и разработчики часто сталкиваются со странным поведением системы при проведении документов движения товаров. Например, при оформлении перемещения между складами программа может упорно отказываться заполнять номера ГТД, выдавать сообщения о нехватке запасов на складе-получателе или игнорировать изменение партий на складе-отправителе.

В этой статье мы подробно разберем, как устроены внутренние механизмы подбора видов запасов, выясним причины «чудес» при проведении перемещений и рассмотрим практические способы решения этих проблем.

---

1. Кэширование и перезаполнение видов запасов: как это работает?

Для оптимизации проведения документов и ускорения работы базы данных разработчики фирмы «1С» применили механизм кэширования видов запасов. Виды запасов хранятся в скрытой одноименной табличной части документа расхода (в нашем случае — в документе Перемещение товаров).

Рассмотрим, в чем заключается главная ловушка этого механизма: если вы просто распроведете документ, а затем проведете его снова без изменения ключевых реквизитов (таких как состав товаров, количество, организация или склады), система не будет перезаполнять виды запасов заново. Она возьмет ранее сохраненные данные из скрытой табличной части. Это защищает систему от лавинообразного изменения партий по всей базе при случайном перепроведении документов задним числом, но сильно усложняет жизнь при исправлении ошибок учета.

Чтобы заставить систему принудительно обновить и перезаполнить виды запасов, мы можем использовать три основных метода:

1. Ручной способ в документе. Открываем документ перемещения, переходим в меню Еще -> Открыть виды запасов. В открывшемся окне нажимаем кнопку «Указать виды запасов вручную», очищаем все строки, после чего нажимаем кнопку «Заполнить автоматически» (или переводим переключатель обратно в режим автозаполнения). После этого проводим документ — система обратится к актуальным регистрам остатков.
2. Программный способ. Если нам нужно перепроводить документы пакетно через обработки, мы можем передать специальный параметр в дополнительные свойства объекта перед его записью. Это заставит систему принудительно очистить и пересчитать табличную часть видов запасов. Рассмотрим пример кода:

// Пример принудительного перезаполнения видов запасов при проведении
ДокументОбъект = СсылкаНаПеремещение.ПолучитьОбъект();
ДокументОбъект.ДополнительныеСвойства.Вставить("ПерезаполнитьВидыЗапасов", Истина);
ДокументОбъект.Записать(РежимЗаписиДокумента.Проведение);

3. Штатный инструмент исправления. Для массового исправления подобных ошибок в программе предусмотрено специальное рабочее место в рамках закрытия месяца — «Помощник исправления остатков товаров организаций». Он самостоятельно находит расхождения между фактическими остатками товаров и распределенными видами запасов и корректирует их.

---

2. Почему не проставляется ГТД, хотя на остатках есть нужная партия?

Иногда возникает ситуация: на складе-отправителе числится ровно одна партия товара с заполненным номером ГТД, но при проведении перемещения в движениях документа (и в видах запасов) ГТД остается пустым. Проанализируем основные причины такого поведения системы:

• Несовпадение налогообложения организаций. Подбор видов запасов жестко завязан на параметры налогообложения. Если партия поступления оприходована на склад по схеме, например, «Продажа облагается НДС», а в документе перемещения склад-получатель или организация предполагают деятельность, не облагаемую НДС (или ЕНВД), система отфильтрует эту партию. Для алгоритма проведения этот товар с данным ГТД окажется недоступным для текущей операции.
• Перекосы (развернутое сальдо) в будущих периодах. Подбор ГТД и видов запасов ориентируется на регистр накопления ТоварыОрганизаций. Если этот номер ГТД уже был ошибочно списан в более поздних документах (даже будущей датой), система заблокирует его использование в текущем документе задним числом, чтобы не допустить появления отрицательного остатка по конкретному номеру ГТД на конец месяца. Контроль остатков организаций в УТ 11 жестко привязан к границам месяцев.
• Ошибки аналитики учета номенклатуры. Самая банальная, но частая причина — пересортица по характеристикам, сериям или схожим позициям номенклатуры (например, при учете одежды схожих моделей). Перед отладкой кода всегда проверяйте совпадение всех разрезов учета вплоть до карточки номенклатуры.

---

3. Откуда берется ошибка «Не хватает товара на складе-получателе»?

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

• Использование схемы «Интеркампани». Если перемещение оформляется между складами, которые закреплены за разными юридическими лицами нашей компании, система моделирует переход права собственности. Если на стороне организации-получателя уже были введены документы продажи этого товара «задним числом» (более поздним временем того же дня или в последующие дни), система при проведении перемещения видит, что на момент тех продаж товара на организации-получателе физически не хватало. Программа требует сначала восстановить хронологию поставок, сигнализируя о нехватке на стороне получателя.
• Статусы документов и переходы «В пути». Если в настройках системы включено использование статусов перемещений (К отгрузке, Отгружено, Принято), то при статусе «Отгружено» товар списывается со склада-отправителя и зависает в регистре «Товары в пути». Если пользователь пытается сразу провести документ в статусе «Принято», но по складу-получателю в эту же секунду проводятся расходные ордера, возникает конфликт блокировок и партионных регистров, выдающий ошибку нехватки обеспечения на принимающей стороне.

---

4. Механизмы FIFO и FEFO в УТ 11: в чем разница?

Среди специалистов часто возникает спор о том, какой метод списания используется в «1С:Управление торговлей 11» — FIFO или FEFO. Проанализируем эту ситуацию и расставим точки над «i»:

В системе параллельно работают два независимых контура учета, которые решают разные задачи:

• Финансовый учет (Себестоимость): Здесь работает классический метод FIFO (ФИФО) — либо скользящая, либо взвешенная оценка (в зависимости от настроек учетной политики). Этот контур определяет, по какой стоимости спишется партия товара в регистре ТоварыОрганизаций и какая себестоимость зафиксируется в финансовом результате.
• Складской учет (Логистика): Метод FEFO (First Expired, First Out) применяется исключительно в складском контуре (регистр Товары на складах). Он задействуется только тогда, когда для номенклатуры настроен учет по сериям с контролем сроков годности. В этом случае система при отгрузке будет предлагать кладовщику забрать с полок товар, у которого быстрее истекает срок годности.

Таким образом, логика подбора серий на складе (по FEFO) и логика списания партий организаций для финансового учета (по FIFO) работают одновременно и дополняют друг друга. Для выравнивания данных между этими контурами учёта можно использовать инструмент для устранения расхождений между регистрами «Товары на складах» и «Товары организаций» в УТ 11.