Разрабатывая функциональность в 1С, мы часто сталкиваемся с необходимостью поиска определенных данных в табличных частях документов. Для этого в платформе существует удобный метод НайтиСтроки, который позволяет быстро отобрать строки по заданным критериям. Однако иногда разработчики сталкиваются с ситуацией, когда этот метод, работающий корректно в тестовой среде или копии базы, внезапно перестает функционировать в рабочей базе, не находя очевидные совпадения. Давайте разберем эту проблему подробнее, выясним возможные причины такого поведения и рассмотрим надежные способы решения.
Первоначальная задача, с которой столкнулся автор темы, заключалась в поиске строки табличной части документа "Заказ Покупателя" по сочетанию Номенклатура и Характеристика. Вот пример кода, который использовался:
Функция ПолучитьЦенуСоскидкой(ДокЗаказ, _Номенклатура,_Характеристика)
ТабТовары = ДокЗаказ.Товар;
ПараметрыОтбора = Новый Структура;
ПараметрыОтбора.Вставить("Номенклатура", _Номенклатура);
ПараметрыОтбора.Вставить("Характеристика", _Характеристика);
НайденныеСтроки = ТабТовары.НайтиСтроки(ПараметрыОтбора);
Если НайденныеСтр.Количество > 0 Тогда
_Цена = НайденныеСтр[0].Цена;
Иначе
Сообщить("Позиция " + _Номенклатура + " "+ _Характеристика + " в заказе не найдена");
Конецесли;
Возврат _Цена;
КонецФункции
При этом, как сообщил автор, совпадения точно есть в документе, а в отладчике все параметры выглядят идентичными. Такая ситуация может вызвать недоумение, но у нее могут быть вполне объяснимые причины.
Мы проанализируем различные аспекты, которые могут влиять на поведение метода НайтиСтроки, начиная от особенностей данных и заканчивая спецификой работы платформы 1С.
Несовпадение типов данных или значений.
На первый взгляд, это самая очевидная, но и самая коварная причина. Визуально значения могут казаться одинаковыми, но на самом деле иметь разные типы или скрытые отличия. Например:
НайтиСтроки выполняет строгое сравнение, включая тип данных. Если в табличной части реквизит Номенклатура имеет тип "СправочникСсылка.Номенклатура", а в качестве параметра отбора передается строка с наименованием номенклатуры, то совпадение не будет найдено. Необходимо убедиться, что тип данных искомого значения полностью соответствует типу данных реквизита табличной части.СправочникСсылка.Номенклатура, СправочникСсылка.ХарактеристикиНоменклатуры) важна не только "визуальная" идентичность, но и идентичность самой ссылки. Даже если две номенклатуры называются одинаково, но являются разными элементами справочника, они будут считаться разными объектами. В отладчике важно проверять не только строковое представление ссылки, но и ее внутренний идентификатор (GUID).НайтиСтроки не найдет совпадение. Для строковых параметров рекомендуется использовать функции СокрЛП(), Врег() или Нрег() для приведения к единому виду перед сравнением, хотя для ссылочных типов это не применимо.Как проверить: Используйте отладчик. Установите точку останова непосредственно перед вызовом НайтиСтроки. В окне "Выражения" добавьте переменные _Номенклатура, _Характеристика и, для примера, ТабТовары[0].Номенклатура, ТабТовары[0].Характеристика. Внимательно сравните их значения и типы. Для ссылочных типов можно посмотреть их строковое представление или попытаться получить их уникальный идентификатор (.УникальныйИдентификатор()).
Неактуальные данные в документе (ссылка вместо объекта).
Еще одна распространенная причина, особенно когда функция вызывается из различных мест системы. Если переменная ДокЗаказ содержит ссылку на документ, а не его объект, и документ был изменен (или не сохранен) после получения этой ссылки, то табличная часть ДокЗаказ.Товар может содержать устаревшие данные из базы данных или быть пустой, если документ был только что создан. Метод НайтиСтроки работает с данными, которые находятся в оперативной памяти в текущий момент.
Как проверить и исправить: Убедитесь, что ДокЗаказ является актуальным объектом документа, данные которого точно соответствуют текущему состоянию в базе. Если вы получаете документ по ссылке, рекомендуется его "прочитать" или получить объект:
// Если ДокЗаказ - это СсылкаНаДокумент
// Преобразуем ссылку в объект, чтобы получить актуальные данные
Если ТипЗнч(ДокЗаказ) = Тип("ДокументСсылка.ЗаказКлиента") Тогда
ОбъектДокумента = ДокЗаказ.ПолучитьОбъект();
Если ОбъектДокумента = Неопределено Тогда
Сообщить("Не удалось получить объект документа " + ДокЗаказ);
Возврат _Цена;
КонецЕсли;
ТабТовары = ОбъектДокумента.Товары; // Используем табличную часть из актуального объекта
ИначеЕсли ТипЗнч(ДокЗаказ) = Тип("ДокументОбъект.ЗаказКлиента") Тогда
ТабТовары = ДокЗаказ.Товары; // Если уже объект, то используем напрямую
Иначе
Сообщить("Некорректный тип параметра ДокЗаказ. Ожидается ссылка или объект документа ЗаказКлиента.");
Возврат _Цена;
КонецЕсли;
Такой подход гарантирует, что мы работаем с самыми свежими данными документа.
Особенности поиска по нескольким параметрам.
Хотя метод НайтиСтроки спроектирован для поиска по нескольким параметрам через структуру, в редких случаях, как отмечают некоторые разработчики 1С (этот "старый баг" упоминается и в сообщении 2), возникают ситуации, когда поиск с двумя или более параметрами ведет себя непредсказуемо. Это может быть связано с особенностями внутренней реализации платформы или кэшированием. В таких случаях по одному параметру поиск работает, а по двум — нет.
Как поступить: Если вы сталкиваетесь с таким поведением, и другие причины исключены, можно использовать альтернативные подходы, о которых мы поговорим в разделе решений. Один из вариантов – это поиск по одному, наиболее уникальному параметру, а затем ручной перебор найденных строк для сравнения остальных параметров.
Дубликаты данных или их нецелостность.
В рабочей базе данных с большой историей и интенсивным использованием могут возникать дубликаты элементов справочников (например, две номенклатуры с одинаковым наименованием, но разными внутренними ссылками). Если в табличной части документа записана одна из таких "дублирующихся" номенклатур, а в параметрах поиска вы передаете другую (даже если она выглядит идентично), НайтиСтроки не найдет совпадения.
Как проверить: Это сложно диагностировать напрямую в отладчике, но можно попробовать выполнить выборочный запрос по табличной части документа, чтобы получить уникальные идентификаторы (GUID) Номенклатуры и Характеристики, а затем сравнить их с параметрами поиска. В идеале, в базе должна быть налажена работа по предотвращению дубликатов.
Странное "эпизодическое" поведение.
Автор темы упомянул очень интересный случай: "Изначально в копии у меня не работало тоже, делала проверки и даже проверила через типа Если _Номенклатура = стр.Номенклатура тогда, в этот момент заработало и я постепенно, убирая проверки, вернула все к первоначальному коду и всё продолжило работать". Такое "самопроизвольное исправление" может указывать на:
Это скорее диагностическое наблюдение, которое указывает на возможные скрытые проблемы, не связанные напрямую с логикой кода.
Отсутствие инициализации переменной _Цена.
Хотя это не причина, по которой НайтиСтроки не находит строки, это важный аспект надежности кода, на который справедливо указали в сообщении 8. Если поиск не даст результата, переменная _Цена останется неопределенной, что при дальнейшем использовании может вызвать ошибку. Всегда инициализируйте возвращаемые значения.
Функция ПолучитьЦенуСоскидкой(ДокЗаказ, _Номенклатура,_Характеристика)
_Цена = 0; // Инициализируем цену, например, нулем
// ... остальной код
Если НайденныеСтр.Количество > 0 Тогда
_Цена = НайденныеСтр[0].Цена;
Иначе
Сообщить("Позиция " + _Номенклатура + " "+ _Характеристика + " в заказе не найдена");
// _Цена уже равна 0, что корректно для "не найдено"
Конецесли;
Возврат _Цена;
КонецФункции
Это гарантирует, что функция всегда вернет числовое значение, даже если позиция не найдена.
После анализа потенциальных причин некорректной работы НайтиСтроки, давайте рассмотрим альтернативные подходы, которые часто оказываются более гибкими и производительными, особенно для больших объемов данных или при поиске по нескольким критериям.
1. Итерационный поиск по одному параметру с последующим перебором
Если метод НайтиСтроки "барахлит" при работе со структурой из нескольких параметров, мы можем обойти это ограничение, используя его для поиска по одному, наиболее уникальному или часто встречающемуся параметру, а затем вручную перебирать полученный массив строк, чтобы отфильтровать по остальным критериям. Этот подход был предложен в сообщении 12.
Когда использовать: Этот метод подходит для небольших табличных частей, где производительность перебора не является критичной проблемой. Он позволяет сохранить объектный подход к работе с данными, не прибегая к запросам.
Определяем основной критерий поиска: Выбираем реквизит, который, предположительно, даст наименьший массив найденных строк или является основным. В нашем случае это может быть Номенклатура, если Характеристика жестко привязана к ней.
Используем НайтиСтроки по одному критерию: Выполняем поиск только по этому основному параметру.
Перебираем полученный массив: В цикле проверяем каждую строку из найденного массива на соответствие остальным критериям.
Рассмотрим пример кода, реализующего этот подход:
Функция ПолучитьЦенуСоскидкой_Итерация(ДокЗаказ, _Номенклатура, _Характеристика)
_Цена = 0; // Инициализируем цену для надежности
// Проверяем и получаем объект документа, чтобы работать с актуальными данными
Перем ОбъектДокумента;
Если ТипЗнч(ДокЗаказ) = Тип("ДокументСсылка.ЗаказКлиента") Тогда
ОбъектДокумента = ДокЗаказ.ПолучитьОбъект();
Если ОбъектДокумента = Неопределено Тогда
Сообщить("Не удалось получить объект документа " + ДокЗаказ + ". Поиск невозможен.");
Возврат _Цена;
КонецЕсли;
ИначеЕсли ТипЗнч(ДокЗаказ) = Тип("ДокументОбъект.ЗаказКлиента") Тогда
ОбъектДокумента = ДокЗаказ;
Иначе
Сообщить("Некорректный тип параметра ДокЗаказ. Ожидается ссылка или объект документа ЗаказКлиента.");
Возврат _Цена;
КонецЕсли;
ТабТовары = ОбъектДокумента.Товары;
// Шаг 1: Ищем по Номенклатуре
// Если Характеристика жестко привязана к Номенклатуре,
// или Номенклатура является более уникальным параметром,
// имеет смысл начать с нее.
ПараметрыОтбораНоменклатура = Новый Структура;
ПараметрыОтбораНоменклатура.Вставить("Номенклатура", _Номенклатура);
НайденныеСтрокиПоНоменклатуре = ТабТовары.НайтиСтроки(ПараметрыОтбораНоменклатура);
// Шаг 2: Перебираем найденные строки и сравниваем Характеристику
Если НайденныеСтрокиПоНоменклатуре.Количество > 0 Тогда
Для Каждого СтрТЧ Из НайденныеСтрокиПоНоменклатуре Цикл
// Проверяем Характеристику
Если СтрТЧ.Характеристика = _Характеристика Тогда
_Цена = СтрТЧ.Цена;
Возврат _Цена; // Найдена первая подходящая строка, можно сразу вернуть цену
КонецЕсли;
КонецЦикла;
КонецЕсли;
// Если дошли до сюда, значит, подходящая позиция не найдена
Сообщить("Позиция " + _Номенклатура + " " + _Характеристика + " в заказе " + ДокЗаказ + " не найдена");
Возврат _Цена;
КонецФункции
Этот подход позволяет обойти возможные проблемы с многопараметрическим поиском в НайтиСтроки, но стоит помнить, что для очень больших табличных частей (десятки тысяч строк) ручной перебор может быть менее производительным по сравнению с запросами к базе данных.
2. Использование запросов к базе данных (Рекомендуемый подход)
Для поиска данных в табличных частях документов, особенно если они могут быть большими или если требуется высокая производительность и гарантия актуальности данных, запросы к базе данных являются наиболее предпочтительным и мощным инструментом. Этот метод был предложен в сообщениях 12 и 13 и является "золотым стандартом" для работы с данными в 1С.
Преимущества запросов:
Рассмотрим подробно пример использования запроса, который был предложен в сообщении 13, и адаптируем его для нашей функции:
Функция ПолучитьЦенуСоскидкой_Запрос(ДокЗаказ, _Номенклатура, _Характеристика)
_Цена = 0; // Инициализируем цену по умолчанию
Запрос = Новый Запрос;
// Устанавливаем параметры запроса.
// Это позволяет избежать инъекций и улучшает читаемость.
// Важно, чтобы передаваемые параметры соответствовали типу данных в базе.
Запрос.УстановитьПараметр("СсылкаДокумента", ДокЗаказ); // Ссылка на документ ЗаказКлиента
Запрос.УстановитьПараметр("ИскомаяНоменклатура", _Номенклатура); // Искомая номенклатура (тип СправочникСсылка.Номенклатура)
Запрос.УстановитьПараметр("ИскомаяХарактеристика", _Характеристика); // Искомая характеристика (тип СправочникСсылка.ХарактеристикиНоменклатуры)
// Формируем текст запроса.
// Мы выбираем только поле Цена из табличной части Товары документа ЗаказКлиента.
// Условия в секции ГДЕ фильтруют строки по Ссылке на документ, Номенклатуре и Характеристике.
Запрос.Текст =
"ВЫБРАТЬ
| ЗаказКлиентаТовары.Цена
|ИЗ
| Документ.ЗаказКлиента.Товары КАК ЗаказКлиентаТовары
|ГДЕ
| ЗаказКлиентаТовары.Ссылка = &СсылкаДокумента
| И ЗаказКлиентаТовары.Номенклатура = &ИскомаяНоменклатура
| И ЗаказКлиентаТовары.Характеристика = &ИскомаяХарактеристика";
// Выполняем запрос и получаем результат в виде объекта Выборка.
Выборка = Запрос.Выполнить().Выбрать();
// Проверяем, удалось ли найти хотя бы одну строку.
// Метод Выборка.Следующий() перемещает курсор к следующей записи и возвращает Истина,
// если запись найдена, или Ложь, если записей больше нет.
Если Выборка.Следующий() Тогда
_Цена = Выборка.Цена; // Получаем значение цены из первой найденной строки
Иначе
// Если ничего не найдено, выводим сообщение пользователю.
Сообщить(СтрШаблон("Позиция %1 %2 в заказе %3 не найдена", _Номенклатура, _Характеристика, ДокЗаказ));
КонецЕсли;
Возврат _Цена;
КонецФункции
Пошаговый разбор запроса:
Создание объекта Запрос: Мы создаем экземпляр объекта Запрос, который будет использоваться для взаимодействия с базой данных.
Установка параметров: С помощью метода УстановитьПараметр мы связываем переменные из нашего кода с именованными параметрами в тексте запроса (например, &СсылкаДокумента). Это важно для безопасности (предотвращает SQL-инъекции) и производительности, так как СУБД может кэшировать планы выполнения запросов с параметрами.
Формирование текста запроса (секция Запрос.Текст):
ВЫБРАТЬ ЗаказКлиентаТовары.Цена: Мы указываем, какие поля хотим получить. В данном случае нам нужна только Цена из табличной части товаров.ИЗ Документ.ЗаказКлиента.Товары КАК ЗаказКлиентаТовары: Здесь мы указываем источник данных. Документ.ЗаказКлиента.Товары – это таблица, которая хранит строки табличной части "Товары" всех документов "Заказ клиента". Мы даем ей псевдоним ЗаказКлиентаТовары для удобства.ГДЕ ЗаказКлиентаТовары.Ссылка = &СсылкаДокумента И ЗаказКлиентаТовары.Номенклатура = &ИскомаяНоменклатура И ЗаказКлиентаТовары.Характеристика = &ИскомаяХарактеристика: Это ключевая секция, где мы задаем условия отбора. Мы отбираем строки, которые принадлежат конкретному документу (по Ссылке) и соответствуют искомым Номенклатуре и Характеристике. Важно, что все эти условия объединяются оператором И, что означает, что все они должны быть истинными для каждой найденной строки.Выполнение запроса и получение выборки: Метод Запрос.Выполнить() отправляет запрос в базу данных и возвращает результат в виде объекта РезультатЗапроса. Затем метод .Выбрать() создает объект Выборка, который позволяет последовательно перебирать полученные записи.
Обход выборки: С помощью конструкции Если Выборка.Следующий() Тогда ... КонецЕсли; мы проверяем, есть ли хотя бы одна запись в результате запроса. Если Выборка.Следующий() возвращает Истина, значит, запись найдена, и мы можем обратиться к ее полям (например, Выборка.Цена). Если записей несколько (хотя в нашем случае ожидается одна), Выборка.Следующий() будет последовательно перемещаться по ним.
Использование запросов является наиболее robustным решением для задач такого рода, поскольку оно напрямую работает с базой данных, гарантируя актуальность и производительность.
Мы выяснили, что проблемы с методом НайтиСтроки могут быть вызваны множеством факторов, от банальных несовпадений типов данных до более сложных проблем с актуальностью данных или особенностями работы самой платформы. Всегда начинайте диагностику с тщательной проверки типов и значений в отладчике.
Для небольших табличных частей и простых условий поиска метод НайтиСтроки может быть вполне адекватным, возможно, с применением итерационного поиска по нескольким параметрам. Однако для надежной, производительной и гибкой работы с данными в 1С, особенно в табличных частях документов, мы настоятельно рекомендуем использовать запросы к базе данных. Они обеспечивают прямой доступ к актуальным данным, высокую скорость выполнения и позволяют реализовать сложную логику отбора, минимизируя риски возникновения "странных" ошибок.