Как в 1С 7.7 быстро найти документ по реквизиту табличной части?

Программист 1С v7.7 Управленческий учет Торговля и дистрибуция
← На главную

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

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

Решение 1: «Графа отбора» — штатный и самый эффективный способ

Самым правильным и «красивым» решением для быстрого поиска по реквизиту табличной части в 1С 7.7 является использование механизма «Графа отбора». Этот инструмент позволяет создать в базе данных специальный индекс по указанному реквизиту, даже если он находится в табличной части. Благодаря индексу поиск происходит практически мгновенно, так как выполняется на уровне СУБД, а не программным перебором в 1С.

Преимущества:

Как настроить графу отбора по шагам:

  1. Откройте конфигурацию в режиме «Конфигуратор».
  2. Найдите нужный документ в дереве метаданных (в нашем случае, «РасходнаяНакладная»).
  3. Откройте свойства документа и перейдите на вкладку «Прочее».
  4. В разделе «Графы отбора» добавьте новую графу.
  5. В свойствах новой графы укажите ее имя (например, «ПоСтикеру») и в качестве источника данных выберите реквизит из табличной части — ТабличнаяЧасть.СтикерПродажи.
  6. Сохраните конфигурацию.

После сохранения платформы 1С создаст необходимые индексы. Теперь вы можете использовать этот отбор в коде для быстрого поиска документов.

Пример использования в коде (концептуальный):


// Создаем объект для выборки документов
ВыборкаДокументов = СоздатьОбъект("Документ.РасходнаяНакладная");

// Устанавливаем отбор по значению нашей графы
// "ПоСтикеру" - имя, которое мы задали в конфигураторе
ИскомыйСтикер = "1234567890";
ВыборкаДокументов.УстановитьОтбор("ПоСтикеру", ИскомыйСтикер);

// Выбираем документы, которые удовлетворяют отбору
ВыборкаДокументов.ВыбратьДокументы(ДатаНачала, ДатаКонца);

Пока ВыборкаДокументов.ПолучитьДокумент() = 1 Цикл
    // Найден документ, в котором есть строка с нужным стикером.
    // Далее можно перебрать его строки, чтобы найти конкретную.
    Сообщить("Найден документ: " + ВыборкаДокументов.ТекущийДокумент());
КонецЦикла;

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

Решение 2: Архитектурные изменения для масштабируемости

Хотя «Графа отбора» отлично решает техническую задачу поиска, сама постановка вопроса может указывать на архитектурные недочеты в системе, особенно в контексте учета продаж через маркетплейсы. Хранение уникального идентификатора заказа в строке расходной накладной — это быстрый, но не всегда дальновидный подход. Рассмотрим более правильные с точки зрения архитектуры варианты.

2.1. Использование отдельного справочника

Этот метод предполагает создание связующего звена между стикером и документом.

Суть метода:

  1. Создается новый справочник, например, «СтикерыПродаж».
  2. В справочнике заводятся реквизиты:
    • СсылкаНаДокумент (тип «Документ.РасходнаяНакладная»)
    • НомерСтроки (тип «Число»)
  3. В качестве основного идентификатора (кода или наименования) используется сам номер стикера.
  4. При проведении документа «РасходнаяНакладная» необходимо программно создавать элементы в этом справочнике для каждой строки, заполняя ссылку на текущий документ и номер строки. При отмене проведения или удалении строки — помечать на удаление соответствующий элемент справочника.

Как происходит поиск:

Поиск становится двухэтапным, но очень быстрым:

  1. Сначала выполняется быстрый поиск по коду или наименованию в справочнике «СтикерыПродаж» с помощью метода НайтиПоКоду() или НайтиПоНаименованию(). Эти методы работают по индексу и выполняются мгновенно.
  2. Из найденного элемента справочника мы сразу получаем прямую ссылку на нужный документ и даже на номер строки в нем.

Плюсы: правильная нормализация данных, очень высокая скорость поиска.

Минусы: усложнение логики проведения и отмены проведения документов, необходимость аккуратного управления связанными данными.

2.2. Использование регистра

Регистры — это стандартный механизм 1С для хранения аналитических данных и построения отчетов. Этот подход является наиболее предпочтительным для построения сложной аналитики.

Суть метода:

  1. Создается новый оборотный регистр, например, «ПродажиПоСтикерам».
  2. В качестве измерения регистра указывается СтикерПродажи (тип «Строка»).
  3. В качестве реквизита (или другого измерения) добавляется ДокументОтгрузки (тип «Документ.РасходнаяНакладная»).
  4. При проведении «РасходнойНакладной» для каждой строки делается движение по этому регистру, записывая в него стикер и ссылку на сам документ.

Как происходит поиск:

Поиск выполняется с помощью объекта Запрос по таблице регистра. Такие запросы работают очень быстро, так как регистры специально оптимизированы для подобных операций.


ТекстЗапроса = "
//[[Запрос
|Период с ДатаНачала по ДатаКонца;
|Стикер = Регистр.ПродажиПоСтикерам.СтикерПродажи;
|Док = Регистр.ПродажиПоСтикерам.ДокументОтгрузки;
|Группировка Док;
|Условие (Стикер = ИскомыйСтикер);
|]";

Запрос = СоздатьОбъект("Запрос");
Если Запрос.Выполнить(ТекстЗапроса) = 0 Тогда
    Возврат;
КонецЕсли;

Пока Запрос.Группировка("Док") = 1 Цикл
    Сообщить("Найден документ: " + Запрос.Док);
КонецЦикла;

Плюсы: стандартный и мощный механизм платформы, высокая скорость, идеально подходит для построения отчетов и аналитики.

Минусы: для заполнения регистра данными за прошлые периоды потребуется массовое перепроведение документов.

Решение 3: Прямые SQL-запросы (для опытных)

Этот способ заключается в обращении напрямую к таблицам базы данных (например, `DT` + номер таблицы для табличных частей документов в формате DBF). Он дает максимальную гибкость, но имеет серьезные недостатки.

Плюсы: возможность выполнять любые, самые сложные запросы, не ограниченные языком запросов 1С.

Минусы:

Выводы и рекомендации

Выбор способа решения зависит от конечной цели.

  1. Если вам нужно быстро решить конкретную задачу поиска и обеспечить фильтрацию в журналах без глобальных переделок, ваш выбор — «Графа отбора». Это просто, эффективно и полностью соответствует штатным возможностям платформы.
  2. Если вы строите долгосрочную систему учета, особенно для работы с маркетплейсами, стоит задуматься об архитектуре. Простой поиск стикера — это лишь верхушка айсберга. В дальнейшем вам потребуется сверять отчеты комиссионера, отслеживать возвраты, корректировать цены продаж. Для таких задач лучше подходит использование регистров. Это позволит создать гибкую и быструю систему для аналитики и отчетности.
  3. Подход с отдельным справочником также является хорошим архитектурным решением, но он больше подходит для обеспечения уникальности и быстрой навигации, чем для построения аналитических отчетов.

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

← На главную