При работе в конфигурации 1С:Бухгалтерия предприятия 3.0 пользователи могут столкнуться с критической ошибкой при попытке проведения документа Корректировка поступления. Текст ошибки обычно выглядит следующим образом: {Документ.КорректировкаПоступления.МодульМенеджера(12544)}: Итератор для значения не определен. Эта проблема парализует работу с исправлением первичных документов и часто ставит в тупик, так как визуально данные в документе и договоре могут выглядеть абсолютно корректно.
В рамках данной статьи мы подробно разберем, почему возникает эта ошибка, проанализируем внутренние механизмы платформы, приводящие к сбою, и рассмотрим пошаговые инструкции по ее устранению различными методами.
Давайте разберем ситуацию с точки зрения программного кода. Ошибка «Итератор для значения не определен» в языке 1С возникает в тот момент, когда программа пытается выполнить цикл Для каждого ... Из ..., но вместо ожидаемой коллекции (массива, таблицы значений, списка значений) ей передается пустое значение Неопределено.
Проанализируем контекст возникновения ошибки в модуле менеджера документа Корректировка поступления. В последних релизах БП 3.0 алгоритм проведения или подготовки данных для печати (например, в процедуре ЗаполнитьПараметрыКорректировки) опирается на настройки договора с контрагентом. Если в договоре установлен признак РасчетыВУсловныхЕдиницах (Расчеты в условных единицах), программа ожидает найти в базе данных сведения о валютных курсах или специфические данные о ставках НДС, которые должны быть представлены в виде коллекции.
Суть проблемы: часто в информационных базах, которые прошли через процедуру переноса данных из 1С:7.7 или ранних версий 2.0, встречаются «битые» договоры. В таких договорах валюта указана как «руб.», но скрытый программный флаг РасчетыВУсловныхЕдиницах установлен в значение Истина. Программа видит этот флаг, заходит в ветку кода для работы с валютой, пытается получить коллекцию данных, получает Неопределено и вылетает с ошибкой итератора.
Рассмотрим подробнее три основных способа решения этой проблемы.
Этот метод подходит в том случае, если документ корректировки создается по относительно новому договору, по которому еще не было заблокировано изменение ключевых реквизитов. Разберем шаги:
Корректировка поступления.При записи объект выполнит стандартные процедуры ПередЗаписью и ПриЗаписи, которые могут пересчитать скрытые реквизиты и привести их в соответствие с визуальными настройками. Однако, если по договору уже есть движения (проводки), система не даст сохранить изменения. В этом случае переходим к следующему шагу.
Если договор старый и заблокирован для редактирования, воспользуемся стандартной обработкой или внешним просмотром и заменой реквизитов. Это самый эффективный способ исправить «испорченные» данные без привлечения программиста для написания кода.
Проанализируем последовательность действий:
Договоры.Расчеты в условных единицах и установим значение Нет (Ложь).Оплата в валюте условных единиц и также установим значение Нет (Ложь).После этой манипуляции флаг в базе данных примет корректное значение Ложь, и документ Корректировка поступления проведется без ошибок.
Для технических специалистов рассмотрим вариант оперативного исправления через внешнюю обработку или консоль кода. Это позволяет точечно воздействовать на объект СправочникОбъект.ДоговорыКонтрагентов.
Пример кода для исправления конкретного договора:
// Определим ссылку на проблемный договор
ДоговорСсылка = Справочники.ДоговорыКонтрагентов.НайтиПоРеквизиту("Номер", "123-А");
Если Не ДоговорСсылка.Пустая() Тогда
ДоговорОбъект = ДоговорСсылка.ПолучитьОбъект();
// Устанавливаем корректные значения для рублевого договора
ДоговорОбъект.РасчетыВУсловныхЕдиницах = Ложь;
ДоговорОбъект.ОплатаВВалютеУсловныхЕдиниц = Ложь;
// Включаем режим обмена данными, чтобы обойти проверки
ДоговорОбъект.ОбменДанными.Загрузка = Истина;
ДоговорОбъект.Записать();
Сообщить("Договор успешно исправлен!");
КонецЕсли;
Использование свойства ОбменДанными.Загрузка = Истина является ключевым, так как стандартный метод Записать() без этого флага вызовет ошибку «По договору уже существуют документы, изменение валюты невозможно».
Если ваша база данных была перенесена из 7.7, мы рекомендуем провести массовую проверку всех активных договоров, чтобы исключить появление ошибки в будущем. Для этого можно воспользоваться «Консолью запросов» и найти договоры с противоречивыми данными.
Проанализируем логику запроса: нам нужны договоры, где ВалютаВзаиморасчетов равна ссылке на «руб.», но при этом РасчетыВУсловныхЕдиницах равно Истина.
ВЫБРАТЬ
Договоры.Ссылка,
Договоры.Владелец КАК Контрагент,
Договоры.Наименование
ИЗ
Справочник.ДоговорыКонтрагентов КАК Договоры
ГДЕ
Договоры.ВалютаВзаиморасчетов.Код = "643"
И (Договоры.РасчетыВУсловныхЕдиницах = ИСТИНА
ИЛИ Договоры.ОплатаВВалютеУсловныхЕдиниц = ИСТИНА)
Если запрос выдаст список элементов, следует применить к ним Способ №2 (Групповое изменение реквизитов), чтобы массово исправить значения. Это предотвратит сбои не только в корректировках поступления, но и в других механизмах (например, в помощнике по учету НДС или при формировании актов сверки), которые также чувствительны к признаку условных единиц.
Таким образом, мы выяснили, что ошибка итератора в БП 3.0 — это не всегда проблема программного кода релиза, а чаще следствие некорректного состояния данных в справочнике. Использование режима Обмен данными = Истина позволяет быстро и безопасно привести базу в порядок.