Как исправить ошибку двойного списания товаров в 1С:УПП 1.3.165.1

← На главную

При использовании конфигурации 1С:Управление производственным предприятием (УПП) редакции 1.3 пользователи столкнулись с серьезной проблемой в релизе 1.3.165.1. Суть ошибки заключается в некорректном формировании движений по регистру Списанные товары, что приводит к фактическому удвоению количества списываемой номенклатуры в документах Требование-накладная, Списание товаров и Перемещение товаров. В этой статье мы подробно разберем, почему это происходит, и как исправить ошибку программно или с помощью обновления.

Анализ причины ошибки: почему происходит двойное списание

Проанализируем ситуацию на примере документа Требование-накладная. Ошибка локализована в модуле документа, в процедуре ДвиженияПоРегиструСписанныеТовары. Проблема возникает только в том случае, если в информационной базе не используется расширенная аналитика учета номенклатуры и затрат (РАУЗ), то есть включен классический партионный учет.

Рассмотрим фрагмент проблемного кода в релизе 1.3.165.1:


Если НЕ глЗначениеПеременной("ИспользоватьРасширеннуюАналитикуУчетаНоменклатурыИЗатрат") Тогда
    ТаблицаСписания = ТаблицаДвижений.Скопировать();
    ОбщегоНазначения.ЗагрузитьВТаблицуЗначений(ТаблицаДвижений, ТаблицаСписания);
    СтруктураШапкиДокумента.Вставить("ТаблицаСписания", ТаблицаСписания);
КонецЕсли;

Разберем по шагам, что здесь происходит не так:

Команда ТаблицаДвижений.Скопировать() создает полную копию таблицы со всеми данными. Если в документе была списана 1 единица товара, в переменной ТаблицаСписания уже находится 1 строка с этим количеством.
Затем вызывается функция ОбщегоНазначения.ЗагрузитьВТаблицуЗначений(ТаблицаДвижений, ТаблицаСписания). Эта функция предназначена для добавления данных из одной таблицы в другую. Поскольку ТаблицаСписания не была очищена перед загрузкой, данные из ТаблицаДвижений добавляются в нее повторно.
В итоге в ТаблицаСписания вместо одной строки оказывается две идентичные строки. При проведении документа система делает два движения по 1 единице, итого списывается 2 единицы товара.

В документе Списание товаров ситуация аналогичная, хотя строки кода могут быть разнесены по разным частям процедуры. Это свидетельствует о системной ошибке при разработке шаблона движений для этого релиза.

Варианты исправления ошибки 30177068

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

Способ 1: Обновление конфигурации (рекомендуемый)

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

Способ 2: Исправление кода вручную

Если обновление в данный момент невозможно (например, конфигурация сильно кастомизирована), необходимо внести изменения в код вручную через конфигуратор. Мы можем пойти двумя путями:

Вариант А: Использование правильного метода копирования колонок. Выясним причину, почему программисты использовали Скопировать(). Если им нужна была только структура таблицы, следовало использовать метод СкопироватьКолонки(). Исправленный код будет выглядеть так:


Если НЕ глЗначениеПеременной("ИспользоватьРасширеннуюАналитикуУчетаНоменклатурыИЗатрат") Тогда
    // Копируем только структуру без данных
    ТаблицаСписания = ТаблицаДвижений.СкопироватьКолонки();
    ОбщегоНазначения.ЗагрузитьВТаблицуЗначений(ТаблицаДвижений, ТаблицаСписания);
    СтруктураШапкиДокумента.Вставить("ТаблицаСписания", ТаблицаСписания);
КонецЕсли;

Вариант Б: Удаление лишней загрузки. Так как ТаблицаСписания уже содержит все необходимые данные после метода Скопировать(), повторная загрузка просто не нужна. Рассмотрим этот вариант:


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

Этот способ является наиболее простым и безопасным для быстрого исправления.

Дополнительная проблема в документе «Поступление товаров и услуг»

Помимо ошибки со списанием, в релизе 1.3.165.1 была обнаружена проблема с механизмом прослеживаемости товаров (РНПТ). Если вы проводите документ Поступление товаров и услуг только по управленческому учету (флаг «Упр. учет» стоит, а «Бух. учет» — нет), программа может выдать ошибку и прервать проведение.

Проанализируем ситуацию: процедура ДвиженияПоРегистрамПрослеживаемыхТоваров() обращается к учетной политике бухгалтерского учета для определения статуса плательщика НДС. При проведении только по «управленке» структура УчетнаяПолитикаРегл не инициализируется. Выясним причину: ранее проверка шла по флагу УчитыватьНДС в шапке документа, а теперь система жестко завязана на параметры регл. учета.

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

Резюме и рекомендации

Подведем итоги нашего анализа:

Релиз УПП 1.3.165.1 содержит критический баг, искажающий складские остатки при партионном учете.
Для исправления необходимо либо обновиться до 1.3.165.2, либо вручную закомментировать строку ОбщегоНазначения.ЗагрузитьВТаблицуЗначений в документах списания и перемещения.
После внесения исправлений крайне важно перепровести документы, созданные в период работы на ошибочном релизе, чтобы восстановить корректные остатки и себестоимость в регистрах.
Будьте внимательны при использовании управленческого учета в документах поступления — механизмы прослеживаемости в данном релизе требуют наличия параметров учетной политики регл. учета.

Помните, что ошибки в типовых решениях — явление редкое для стабильных веток вроде УПП, но требующее немедленной реакции технического специалиста для сохранения целостности данных предприятия.