Какие задачи и вопросы с подвохом использовать для проверки реального опыта программиста 1С

← На главную

Оценка квалификации разработчика 1С на собеседовании часто осложняется тем, что типовые теоретические вопросы легко заучиваются, а простые задачи быстро гуглятся в интернете. Чтобы быстро отличить специалиста с практическим опытом разработки от новичка, изучившего базовую теорию, целесообразно использовать компактные задачи и контрольные вопросы с неочевидными нюансами поведения платформы. Разберем наиболее эффективные практические кейсы, алгоритмические задачи и темы для экспресс-тестирования.

Задача 1: Поиск часто встречающихся пар товаров в документах

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

Здесь проверяется умение кандидата работать со связыванием таблицы самой с собой, исключать дубликаты пар (чтобы пара «Товар А — Товар Б» не дублировалась как «Товар Б — Товар А») и корректно группировать данные.

Проанализируем пример реализации такого запроса:


ВЫБРАТЬ РАЗЛИЧНЫЕ
    ТабТовары.Ссылка КАК Документ,
    ТабТовары.Номенклатура.Код КАК Код
ПОМЕСТИТЬ ВТ_Товары
ИЗ
    Документ.РеализацияТоваровУслуг.Товары КАК ТабТовары
ГДЕ
    ТабТовары.Ссылка.Проведен = ИСТИНА
;

////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ
    ВТ1.Код + " - " + ВТ2.Код КАК ПараТоваров,
    ВТ1.Документ КАК Документ
ПОМЕСТИТЬ ВТ_Пары
ИЗ
    ВТ_Товары КАК ВТ1
        ВНУТРЕННЕЕ СОЕДИНЕНИЕ ВТ_Товары КАК ВТ2
        ПО ВТ1.Документ = ВТ2.Документ
            И ВТ1.Код > ВТ2.Код
;

////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ
    ВТ_Пары.ПараТоваров КАК ПараТоваров,
    КОЛИЧЕСТВО(ВТ_Пары.Документ) КАК КоличествоСлучаев
ИЗ
    ВТ_Пары КАК ВТ_Пары
СГРУППИРОВАТЬ ПО
    ВТ_Пары.ПараТоваров
УПОРЯДОЧИТЬ ПО
    КоличествоСлучаев УБЫВ

Обратим внимание на ключевой момент в условии соединения: использование строгого неравенства ВТ1.Код > ВТ2.Код исключает повторный учет перевернутых пар и объединение товара с самим собой.

Задача 2: Построение иерархии в СКД без использования иерархического справочника

Разберем нестандартную задачу для системы компоновки данных. Имеется неиерархический справочник, у которого добавлен реквизит Родитель (ссылка на этот же справочник). Требуется вывести дерево элементов в отчете средствами СКД.

Кандидат без глубокого понимания СКД попытается вручную соединять таблицы в запросе с ограничением по уровням вложенности. Опытный специалист сразу применит встроенный механизм связей наборов данных:

Создаем набор данных — запрос, выбирающий ссылку, родителя и необходимые реквизиты справочника.
Переходим на закладку Связи наборов данных и настраиваем связь набора с самим собой: источник связи — наш набор данных, приемник — этот же набор данных.
В поле Условие связи связываем поле Ссылка с полем Родитель.
В поле Начальное значение указываем значение для элементов верхнего уровня (например, пустая ссылка или NULL).
В настройках структуры отчета для группировки выбираем тип вывода Иерархия.

Задача 3: Срез последних на каждую дату документа

Выясним частую проблему при формировании реестра документов: требуется вывести документы за период и пересчитать суммы в другую валюту по курсу на дату каждого конкретного документа.

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

Микровопросы по поведению запросов и СУБД

Рассмотрим контрольные вопросы, ответы на которые позволяют за 5–10 минут определить глубину понимания механизмов платформы:

Разыменование полей составного ссылочного типа: к чему приводит обращение через точку к реквизиту поля составного типа (например, Регистратор.Контрагент)? Опытный разработчик ответит, что это порождает неявные левые соединения со всеми таблицами типов, входящими в состав реквизита, что приводит к сильному замедлению запроса. Для решения проблемы применяется явное ограничение типа функцией ВЫРАЗИТЬ(... КАК ...).
Фильтрация в секции ГДЕ при левом соединении: что произойдет, если наложить условие на реквизит правой таблицы в блоке ГДЕ без проверки на ЕСТЬ NULL? Такое условие фактически превращает ЛЕВОЕ СОЕДИНЕНИЕ во ВНУТРЕННЕЕ СОЕДИНЕНИЕ, отсекая строки левой таблицы, для которых нет соответствия справа.
Параметры виртуальной таблицы против секции ГДЕ: почему условие по номенклатуре в регистре остатков обязательно передавать в параметры виртуальной таблицы, а не в блок ГДЕ? Условие в параметрах накладывается на уровне СУБД до расчета итогов, а блок ГДЕ выполняет постобработку всей полученной таблицы остатков.
Разница между ОБЪЕДИНИТЬ и ОБЪЕДИНИТЬ ВСЕ: ключевое слово ОБЪЕДИНИТЬ без ВСЕ выполняет неявную группировку и устранение дубликатов строк, создавая избыточную нагрузку на сервер. По стандарту разработки следует всегда использовать ОБЪЕДИНИТЬ ВСЕ, если дубликаты допустимы или их отсутствие гарантировано.
Строки неограниченной длины: почему платформа запрещает группировать или соединять таблицы по строкам неограниченной длины? В СУБД такие поля хранятся как большие объекты (LOB/TEXT), к которым неприменимы стандартные индексы. В запросе требуется явно ограничить длину: ВЫРАЗИТЬ(Поле КАК Строка(100)).

Алгоритмическая задача: Распределение суммы с учетом копейки

Проанализируем простую прикладную задачу: распределить общую сумму пропорционально коэффициентам или долям строк в табличной части.

Специалист с практическим опытом сразу обратит внимание на проблему округления: сумма округленных значений по строкам почти никогда не сходится с исходной суммой ровно в копейку. Решение этой проблемы показывает знание прикладных стандартов разработки: остаток округления («копейка») относится на первую или последнюю строку табличной части либо распределяется по строкам с наибольшими долями.

Проверка навыков отладки и чтения чужого кода

Эффективный метод тестирования — моделирование реальной ошибки в тестовой базе. Кандидату предоставляется база данных с готовым сценарием:

В документ или отчет закладывается логическая ошибка (например, документ начисления зарплаты не рассчитывает удержание, так как по сотруднику уже зарегистрирован аналогичный документ-регистратор в этом периоде).
Соискателю предлагается запустить конфигуратор, использовать точку останова или замер производительности и локализовать причину поведения программы.

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