Почему документ «Корректировка реализации» делает движения по прослеживаемости, если опция отключена, и как это исправить

Программист 1С v8.3 (Управляемые формы) 1С:Комплексная автоматизация Налоговый учет
← На главную

В процессе работы с конфигурациями на базе 1С:ERP, 1С:Комплексная автоматизация 2 или 1С:Управление торговлей 11 (особенно в релизах ветки 2.5.7 и ранних 2.5.8) пользователи и программисты часто сталкиваются с необъяснимым поведением системы. Одной из таких проблем является попытка документа Корректировка реализации сформировать записи в регистре сведений Операции с прослеживаемыми товарами, даже если функциональная опция Использовать учет прослеживаемых импортных товаров полностью отключена в настройках системы.

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

Анализируем причину возникновения проблемы

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

Проанализируем, почему система вообще «заглядывает» в этот регистр при выключенной опции. В архитектуре 1С:ERP/КА формирование движений часто происходит через универсальные механизмы. Проблема заключается в том, что в старых версиях кода запрос, подготавливающий данные для этого регистра, не проверяет значение функциональной опции. Вместо этого он ориентируется на наличие данных в таблице Виды запасов.

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

Выясняем причину ошибки «Запись с такими измерениями уже существует»

Когда запрос находит записи с РНПТ, он пытается сформировать набор данных для записи в регистр сведений. Ошибка дублирования возникает из-за того, что в старых релизах конфигураций этот запрос не содержал оператора РАЗЛИЧНЫЕ или надлежащей группировки.

Поскольку в регистре Операции с прослеживаемыми товарами измерениями являются Организация, Контрагент, Номер ГТД и ряд других полей, но отсутствует Номенклатура или Номер строки, при наличии в одной корректировке двух и более строк с одинаковым РНПТ (но, например, разными ценами), система пытается записать в регистр две абсолютно одинаковые по измерениям строки. Это и приводит к невозможности проведения документа.

Технический разбор: как выглядит ошибочный код

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


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

    // Формирование временной таблицы на основе видов запасов
    ТекстЗапроса = 
    "ВЫБРАТЬ
    |    ВтВидыЗапасовКорректировкаВыручки.НомерСтроки КАК НомерСтроки,
    |    &Период КАК Период,
    |    &Организация КАК Организация,
    |    &Контрагент КАК Контрагент,
    |    ЗНАЧЕНИЕ(Справочник.ТипыДокументов.Накладная) КАК ТипДокументаВПрослеживаемости,
    |    ВтВидыЗапасовКорректировкаВыручки.ВидЗапасов.ТипЗапасов КАК ТипЗапасов,
    |    ВтВидыЗапасовКорректировкаВыручки.НомерГТД КАК НомерГТД
    |ИЗ
    |    ВтВидыЗапасовКорректировкаВыручки КАК ВтВидыЗапасовКорректировкаВыручки";
    
    // В этом запросе НЕТ отбора по типу номера ГТД и нет группировки!
    
    ТекстыЗапроса.Добавить(ТекстЗапроса, ИмяРегистра);
    Возврат ТекстЗапроса;
КонецФункции

Как мы видим, в данном запросе полностью отсутствует фильтрация по типу ГТД. Следовательно, если в документе есть любой Номер ГТД, система попытается сделать запись в регистр прослеживаемости, что в корне неверно.

Варианты решения проблемы

Рассмотрим два основных пути исправления ситуации:

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

Пошаговое исправление кода запроса

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

  1. Добавить проверку типа номера ГТД (обрабатывать только РНПТ).
  2. Использовать ключевое слово РАЗЛИЧНЫЕ для исключения дублирующих записей по измерениям.

Проанализируем правильный вариант кода, который используется в современных версиях 1С:КА:


// Внесем изменения в текст запроса
ТекстЗапроса = 
"ВЫБРАТЬ РАЗЛИЧНЫЕ
|    &Период КАК Период,
|    &Организация КАК Организация,
|    &Контрагент КАК Контрагент,
|    ЗНАЧЕНИЕ(Справочник.ТипыДокументов.Накладная) КАК ТипДокументаВПрослеживаемости,
|    ВЫБОР
|        КОГДА &ВидКорректировки = ЗНАЧЕНИЕ(Перечисление.ХозяйственныеОперации.ИсправлениеОшибок)
|            ТОГДА ЗНАЧЕНИЕ(Перечисление.ПорядокОтраженияВОтчетностиПоПрослеживаемости.КнигаПродаж)
|        КОГДА ВтВидыЗапасовКорректировкаВыручки.СуммаВзаиморасчетов < 0
|            ТОГДА ЗНАЧЕНИЕ(Перечисление.ПорядокОтраженияВОтчетностиПоПрослеживаемости.КнигаПокупок)
|        ИНАЧЕ ЗНАЧЕНИЕ(Перечисление.ПорядокОтраженияВОтчетностиПоПрослеживаемости.КнигаПродаж)
|    КОНЕЦ КАК ОтражениеВОтчетности,
|    ВтВидыЗапасовКорректировкаВыручки.ВидЗапасов.ТипЗапасов КАК ТипЗапасов
|ИЗ
|    ВтВидыЗапасовКорректировкаВыручки КАК ВтВидыЗапасовКорректировкаВыручки
|ГДЕ
|    (ВтВидыЗапасовКорректировкаВыручки.НомерГТД.ТипНомераГТД = ЗНАЧЕНИЕ(Перечисление.ТипыНомеровГТД.НомерРНПТ)
|    ИЛИ ВтВидыЗапасовКорректировкаВыручки.НомерГТД.ТипНомераГТД = ЗНАЧЕНИЕ(Перечисление.ТипыНомеровГТД.НомерРНПТКомплекта))";

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

Пример упрощенного фильтра, если нужно быстро «отсечь» лишние движения:


|ГДЕ
|    ВтВидыЗапасовКорректировкаВыручки.НомерГТД.РНПТ = ИСТИНА";

Как проверить результат?

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

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

← На главную