Отбор кандидата-программиста
Функциональные - Управление персоналом (HRM)
Файлы
ВНИМАНИЕ: Файлы из Базы знаний - это исходный код разработки. Это примеры решения задач, шаблоны, заготовки, "строительные материалы" для учетной системы. Файлы ориентированы на специалистов 1С, которые могут разобраться в коде и оптимизировать программу для запуска в базе данных. Гарантии работоспособности нет. Возврата нет. Технической поддержки нет.
| Наименование | Скачано | Купить файл | По подписке PRO |
|---|---|---|---|
|
Шаблон ответов для тестового задания
.docx 13,51Kb
29
|
29 | 4 200 руб. Купить | 5 SM Скачать |
|
по статье infostart.ru/1c/articles/2322667 ответы на вопросы 8 - 14
.docx 21,59Kb
7
|
7 | 4 200 руб. Купить | 5 SM Скачать |
|
по статье infostart.ru/1c/articles/2322667 ответы на вопросы 1 - 7
.docx 16,86Kb
7
|
7 | 4 200 руб. Купить | 5 SM Скачать |
Подписка PRO — скачивайте любые файлы со скидкой до 85% из Базы знаний
Оформите подписку на компанию для решения рабочих задач
Оформить подписку и скачать решение со скидкойВы можете заказать платную доработку или адаптацию этой разработки под вашу конфигурацию на «Бирже заказов».
- 0% комиссии — оплата напрямую исполнителю;
- Исполнители любого масштаба — от отдельных специалистов до команд под проект;
- Прямой обмен контактами между заказчиком и исполнителем;
- Безопасная сделка — при необходимости;
- Рейтинги, кейсы и прозрачная система откликов.
Мне часто приходится участвовать в собеседованиях (отборе) кандидата-программиста. Постепенно пришел к выводу, что написание по техническому заданию новой обработки (отчета) – не лучший вариант:
- Требуется существенное время + среда разработки (компьютер)
- Может вызвать негативную реакцию.
- Для проверки требуется сотрудник высокой квалификации.
- Увеличение длительности отбора увеличивают вероятность отказа кандидата от участия.
Поэтому было решено давать кандидату уже написанный код 1С с ошибками, которые он должен найти.
- Поиск ошибок в чужом коде происходит быстро, читать - с листа.
- Повышает самооценку кандидата.
- Результат можно проверить по шаблону ответов
Ниже образец кода 1С с ошибками, применяемый для собеседования. Шаблон ответов приложен к публикации. Цена файла предназначена для крупных корпораций, не для персонального использования )) Этот текст - обладает вескими достоинствами:
1) Короткий
2) Быстрый
3) Самодостаточный. Каждая неточность (ошибка) поясняется самим текстом или ИТС.
4) Дает оценку кандидата по шкале от 0 до 20.
Не каждый ребенок найдет здесь 20 неточностей (ошибок), да ? Кандидат должен сделать максимально глубокий разбор с учётом всех возможных нюансов и контекстов кода 1С.
&НаКлиентеНаСервере
Функция ЗаполнитьЗначенияСвойств() //01
Запрос = Новый Запрос; //03
Запрос.Текст =
"ВЫБРАТЬ РАЗРЕШЕННЫЕ РАЗЛИЧНЫЕ //05
| ВыручкаИСебестоимостьПродажОбороты.Регистратор.АдресДоставки КАК АдресДоставки,
| ВыручкаИСебестоимостьПродажОбороты.АналитикаУчетаНоменклатуры.Номенклатура КАК Номенклатура, //07
| ВыручкаИСебестоимостьПродажОбороты.АналитикаУчетаНоменклатуры.Характеристика КАК ХарактеристикаНоменклатуры,
| ВыручкаИСебестоимостьПродажОбороты.КоличествоОборот * ЦеныНоменклатурыСрезПоследних.Цена КАК СуммаОборот //09
|ИЗ
| РегистрНакопления.ВыручкаИСебестоимостьПродаж.Обороты(&ДатаНачала, &ДатаОкончания, Регистратор, ) КАК ВыручкаИСебестоимостьПродажОбороты //11
| ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.ЦеныНоменклатуры.СрезПоследних(&ДатаОкончания, ВидЦены = &ВидЦены) КАК ЦеныНоменклатурыСрезПоследних
| ПО ВыручкаИСебестоимостьПродажОбороты.АналитикаУчетаНоменклатуры.Характеристика = ЦеныНоменклатурыСрезПоследних.Характеристика //13
|ГДЕ
| ЦеныНоменклатурыСрезПоследних.Номенклатура В(&ГруппаНоменклатуры) //15
| И ВыручкаИСебестоимостьПродажОбороты.Регистратор ССЫЛКА Документ.РеализацияТоваровУслуг";
//17
Запрос.УстановитьПараметр("ВидЦены", ВидЦены);
Запрос.УстановитьПараметр("ДатаНачала", НачалоМесяца( ТекущаяДата() ) ); //19
Запрос.УстановитьПараметр("ДатаОкончания", КонецДня( ТекущаяДата() ) + 1 );
Запрос.УстановитьПараметр("ГруппаНоменклатуры", ГруппаНоменклатуры); //21
РезультатЗапроса = Запрос.Выполнить();
ТЗ = РезультатЗапроса.Выгрузить(); //23
НачатьТранзакцию();
//25
Для Каждого СтрокаДанных ИЗ ТЗ Цикл
Сообщить( СтрокаДанных.АдресДоставки + " " + СтрокаДанных.Номенклатура + " " + СтрокаДанных.СуммаОборот ); //27
КонецЦикла;
//29
ЗафиксироватьТранзакцию();
//31
КонецФункции;
Вступайте в нашу телеграмм-группу Инфостарт
Собеседование тестирование интервью кандидат прием на работу
См. также
Управление персоналом (HRM) Бухгалтер Пользователь 1С:Предприятие 8 Бухгалтерский учет Управленческий учет Платные (руб)
1С:Зарплата и управление персоналом 8 – программа для полной автоматизация учета и управления сотрудниками на предприятии. Базовая, КОРП и ПРОФ версии. Покупайте в Инфостарт и получайте 15% бонусов на наши услуги, сервисы и мероприятия!
11100 руб.
17.02.2016 178949 802 6
Управление персоналом (HRM) Бухгалтер 1С:Предприятие 8 1С:Зарплата и кадры бюджетного учреждения 1С:Управление производственным предприятием 1С:ERP Управление предприятием 2 1С:Бухгалтерия 3.0 1С:Комплексная автоматизация 2.х 1С:Зарплата и Управление Персоналом 3.x Россия Бухгалтерский учет Платные (руб)
Решение дает набор актуальных на текущий год форм бланков для ведения миграционного учёта по иностранным работникам в «1С:Зарплата и Управление Персоналом 8», «1С:Бухгалтерия 8», «1С:ERP 8», «1С:Комплексная Автоматизация 8» и других конфигураций 1С. Интеграция с Госуслугами. Дополнительная опция – автоматическая проверка по Реестру контролируемых лиц (РКЛ).
7950 руб.
06.02.2012 136971 104 88
Управление персоналом (HRM) Россия Платные (руб)
Сервис автоматической массовой проверки иностранных сотрудников в реестре контролируемых лиц и отправки уведомлений в МВД. Защитите свой бизнес от штрафов до 2 млн руб, автоматизировав контроль за нарушениями иностранных сотрудников и взаимодействие с МВД. Снижение рисков на 95%
05.05.2026 934 2 user2197699 0
Управление персоналом (HRM) Комплексное управление ресурсами (ERP) Бизнес-аналитика (BI) Пользователь 1С:Предприятие 8 Россия Управленческий учет Платные (руб)
Решение предназначено для управления результативностью организации с использованием ключевых показателей деятельности (KPI) и сбалансированной системы показателей (BSC)
57800 руб.
17.02.2016 42000 2 1
Управление персоналом (HRM) Учет рабочего времени 1С 8.3 1С:Бухгалтерия 3.0 Россия Платные (руб)
Расширение «Отпуска» добавляет в конфигурацию 1С:Бухгалтерия предприятия возможность формировать печатную унифицированную форму № Т-7 "График отпусков". Также реализован лёгкий процесс подачи и согласования заявлений на отпуск: сотрудник или бухгалтер создаёт заявление, указывает период и замещающих; руководитель утверждает или отклоняет. При желании сотрудники, руководитель и замещающие получают уведомления о событиях в Битрикс24. Вся работа ведётся прямо в 1С:Бухгалтерия предприятия, без установки тяжёлых кадровых контуров либо сложных интеграций.
18300 руб.
13.10.2026 189 0 0
Управление персоналом (HRM) Бесплатно (free)
В статье разбираем, как DISC-модель помогает понять, почему сотрудники по-разному реагируют на задачи, изменения и взаимодействие в команде. Кратко объясняем основы подхода и поведенческие типажи без сложной теории, показываем, какие сочетания чаще встречаются в IT-среде. Рассказываем, как особенности разных типов влияют на коммуникацию, распределение ролей и рабочие процессы. Показываем, как учитывать эти различия на практике – при постановке задач, управлении и формировании эффективных команд.
17.09.2026 1065 user2086401 1
Управление персоналом (HRM) 1С 8.3 1С:Зарплата и Управление Персоналом 3.x Россия Абонемент ($m)
В ЗУП 3.1.38.92 при ручной загрузке запросов СФР старого формата СЭДО 100 может возникать ошибка «Метод объекта не обнаружен (ЗагрузитьСообщение100)». В результате XML-файл запроса недостающих сведений не загружается, хотя сам файл сформирован корректно. Публикация содержит временное расширение для ЗУП 3.1.38.92, возвращающее обработку сообщений СЭДО 100 без изменения типовой конфигурации. Решение предназначено для использования до выхода официального исправления 1С и особенно актуально в переходный период на новые типы сообщений СЭДО. Расширение минимально вмешивается в типовой механизм и устраняет ошибку загрузки старых запросов СФР.
1 стартмани
16.09.2026 950 5 e_lenochka 2
Управление персоналом (HRM) 1С:Зарплата и Управление Персоналом 3.x Россия Абонемент ($m)
Обработка подсчитывает количество оформленных отпусков сделанных исполнителем за период. Включены отпуска без оплаты на часы отсутствия.
1 стартмани
16.09.2026 400 0 AlenaBelousova 0
А то статья обесценится, вынужден буду комментарии закрыть.
и
Запрос.УстановитьПараметр("ДатаНачала", НачалоМесяца( ТекущаяДата() ) ); //19
Запрос.УстановитьПараметр("ДатаОкончания", КонецДня( ТекущаяДата() ) + 1 );
попахивает "инфоцыганством".... (новый граница....)
Этот код обязан вызывать вопросы и неприязнь ))
Сильный программист видит все ошибки самостоятельно, платная подсказка ему не нужна.
Цена в рублях вообще с потолка берется, я ей не управляю.
Если бы я публиковал свои примеры рефакторинга, наверно уже миллионером был :)
В задаче говнокод. В ответе результат рефакторинга.
У меня такого "придуманного" кода на проекте мама не горюй ;D
РезультатЗапроса = Запрос.Выполнить();
ТЗ = РезультатЗапроса.Выгрузить(); //23
НачатьТранзакцию();
//25
Для Каждого СтрокаДанных ИЗ ТЗ Цикл
Сообщить( " " + СтрокаДанных.АдресДоставки + " " + СтрокаДанных.Номенклатура + " " + СтрокаДанных.СуммаОборот ); //27
КонецЦикла;
//29
ЗафиксироватьТранзакцию(); Показатьна
РезультатЗапроса = Запрос.ВыполнитьПакет();
Выборка = РезультатЗапроса.Выбрать(ОбходРезультатаЗапроса.ПоГруппировкам); //23
Попытка //25
Если Выборка.Следующий(Истина) Тогда //27
НачатьТранзакцию();
//29
Для Каждого СтрокаДанных ИЗ Выборка
Сообщить СтрокаДанных.Сумма + " " + СтрокаДанных.Номенклатура + " " + СтрокаДанных.АдресДоставки ; //31
КонецЦикла;
//33
КонецЕсли
//35
КонецПопытки;
//37
ЗафиксироватьТранзакцию(); ПоказатьКстати, вот, тут ещё имеет смысл разделять весь процесс исправления на три задачи:
1. Просто оптимизировать ошибки - чтобы код "не падал", или умел падать корректно, когда иначе никак в многопользовательской клиент-серверной среде (да и без неё - в 1С Предприятие 8 будет 1001 повод упасть на ровном месте, особенно когда нет чёткого представления о том, как вызывается такой код - если это не явная интерактивная работа в УФ), но с приоритетом на надёжность (а нюансов по входным данным может быть множество, даже на микрообъёмах)
2. Оптимизация кода уже с приоритетом на скорость работы и скорость внесения такой доработки (с сохранением безотказности, насколько будет возможно) при работе, в условно, не очень сильно загруженной среде, но, с неизвестными объёмами входных данных, потенциально, как малыми, так и крайне большими
3. Оптимизация кода, когда, в основном, работа идёт с данными умеренно среднего объёма, но в очень конкурентной "пользовательской" среде - когда вероятность многократных ежесекундных пересечений по данным близка к 100%, а число сеансов более 10К, число серверов в кластере, более 10-ка
Это я к тому, что оптимизировать/исправлять можно практически любой код, и увлечься в этом процессе очень сильно - но нужно чётко понимать требуемые границы результата/времени и целевой вектор направления такой оптимизации!
Да и вообще, одно дело - это код, условно, проведения или интерактивной работы документа, в т.ч. в форме списка. Другое дело - это часто запускаемый отчёт, и третье дело - это отчёт, выполняемый по сложной схеме, ночью, с с рассылкой результата. Или это какие-либо фоновые процессы. Или это код регл. обработки, запускаемый несколько дней в месяц, но вешающий всю базу на 8 часов, а то и больше!
Но тут, конечно, тогда надо разделять и того - кого Вы ищите:
0. Стажёра/начинающего программиста
1. Просто эффективного опытного кодера
2. Аналитика-разработчика
3. Архитектора-эксперта
(4. а ведь ещё это может быть и внедренец/консультант - но это уже другая тема; как тема тестирования)
Для них всех нужны свои задачи, и разный объём области анализа/вмешательства.
Но, вообще, идея проверять знания на готовой кодовой базе - вполне себе неплохая, и имеет право применения в практике крупных компаний, да и мелких тоже!
Кстати, ещё одним хорошим методом (если это актуально, конечно) - может быть задача на проведение обновления релиза изменённой конфигурации (с или без применения git или трёхстороннего сравнения - это уже индивидуально) для специально подготовленной заковыристой конфигурации, с разумным числом изменений. Ну или просто задача слияния нескольких конфигураций. А если в базе ещё будет и несколько дополнительных (доработанных) отчётов/печатных форм, или просто отдельных клонов форм объектов метаданных - так вообще будет шикардос (по идеи - на этом должны засыпаться более половины кандидатов - просто не обратив на это внимание - а ведь, это очень важно понимать, ну и глубокая внимательность тут хорошо проверяется)!
Я специально сделал акцент на том, что это должна быть специально подготовленная конфигурация. С ограниченным числом изменений (специально подобранными для моделирования тех или иных заковыристых практических ситуаций - эдакая квинтэссенция) и таким же заранее подготовленным чек-листом!
Не надо ставить рабочую задачу - она изначально должна быть тестовой - и это должно быть видно. Можно вообще использовать не типовую небольшую конфигурацию. Чтобы и кандидату показать - что это только тест, за разумное время - скажем за 1 час, не более (в идеале - минут 20-30 уже профи должно хватить, с объёмом не стоит перебарщивать, хотя, безусловно, при обновлении объёмы играет важную роль - когда долго обновляешь, устаёшь и "глаз замыливается" - и вообще - обновление сложных конфигураций это сам по себе хороший повод провести и оптимизацию и автоматизацию части процесса, и настроить автотесты - но это всё уже совсем другая тема, всё-таки сейчас речь только про тестирование навыков кандидата - так что только полностью ручной хардкор на внимательность и умение разбираться в алгоритмах; и только на малых объёмах). А сильно изменённые рабочие конфигурации могут обновляться всего на один шаг обновления релиза - не один день, с сотнями изменённых элементов метаданных. С тысячами изменённых строк кода/ячеек/элементов форм. Это сразу будет видно - и так делать, конечно, нельзя!
наверное тест имеет разумные ограничения "от джуна до мидла" ))
и да, мне отчасти неловко (или даже завидно), что комментарий (42) больше основной статьи ))
Приведённый Вами в сабже - скорее всего - да (хотя там есть отсылки к определениям, вне приведённой кодовой базы, ну и в 1С Предприятие 8 не строго типизированный ЯП, так что тут ошибки могут ещё и в рантайме всплыть - и это вообще хороший вопрос от кандидата - стоит ли заморачиваться с проверкой входных типов - или есть гарантия их корректности) - но я ответил на пост, с предложенным альтернативным кодом!
Кстати, сразу не обратил внимание, тут ещё и нюансы с правами доступа могу быть - что тоже никак не оговорено. Хоть в запросе и явно написано "ВЫБРАТЬ РАЗРЕШЕННЫЕ РАЗЛИЧНЫЕ" - но, ведь, это не панацея от всех проблем с доступом, а лишь отчасти для RLS! А если ещё и профили доступа КОРП лицензий приплести.... В общем - вопросы решения проблем с доступом тут тоже явно требуют уточнения: либо надо решать - и тогда "подводных камней" можно много заложить, либо не надо и ограничиваемся явно заданной/или специально не заданной конструкцией "ВЫБРАТЬ РАЗРЕШЕННЫЕ "!
Не обращайте внимание, к сожалению, это моя плохая привычка - я люблю писать ёмкие комментарии :-(
Другое дело - какой-то навороченный пример, где результат собирается из временных таблиц, в разных режимах привилегированных модулей. Я вот, забыл, как будет вести себя временная таблица в таком случае.
Ранее, данные возвращались, пока не доходило до выборки в объектную модель - там в значениях ссылочных полей уже были записи "Объект не найден". Сейчас, вроде как, возникает ошибка при вызове запроса. У меня не используется RLS - вот я не знаю как сейчас!
Или, всё же, "баг ревью"?
Ничего не имею против обоих подходов, но надо понимать, что это разные вещи, и кандидату должна правильно ставиться задача - или Вы медиумов ищите?
А, впрочем, дело ваше... в какой-то степени можно написать и условно верные конструкции, в расчёте на то, что кандидат сочтёт их явно ошибочными - и удалит!
Но, на мой взгляд, в строке 05 - кандидату в режиме чисто "код ревью" не нужно ничего ни исправлять ни комментировать! Тем более, если у него нет данных о настройке ролей метаданных и установке опций в ИБ
Несмотря на то, что в этой строке есть ещё одна директивы "РАЗЛИЧНЫЕ", которая, так же как и "РАЗРЕШЕННЫЕ" в данном коде, ничего особо плохого не делает, но.... может быть нужной, в зависимости от фактической структуры измерений "ЦеныНоменклатуры" .
И это я только одну строчку кода обсудил - а, по сути, тут придираться можно к условной "ошибочности" почти каждой номерной строки (и кода около ней). Безусловно - если у кандидата будет более детальная постановка задачи и условий контекста выполнения такого кода - то ситуация может сильно меняться. Безусловно - если кандидат очень опытный - он сам Вам задаст вопросов больше, чем Вы ему! Безусловно - если кандидат супер опытный - он такой подход вообще сочтёт издевательством (ну если его, конечно не берут на должность куратора к группе немощных кодеров), и 1001 раз подумает - а надо ли ему сюда идти!
Номер в строке - это не показатель ошибки, это просто нумерация. Чтобы было удобнее код обсуждать.
Хотя бы уточнили ключевые особенности метаданных, самой ИБ, и нагрузке на неё. Я, которые влияют на принятие решений.
Я, вот, не сразу понял (пришлось перебрать пару конфигураций), что тут, вероятно конфигурация УТ 11.4 (КА 2.4, ERP2.4 - нужное подчеркнуть), т.к *.5 версии указанных метаданных нет; и это ещё без учёта того, что это может быть и не типовая конфигурация вовсе, или доработанная типовая - а значит и структура метаданных может быть иной! А архитектура метаданных в Ваших задачах и, вероятно, в Вашем подходе - скорее всего, имеет важное значение.
Даже в данном примере в типовой конфигурации (скажем УТ - в строке 5 - ключевое слово "РАЗРЕШЕНО" формально лишнее но:
1. Только если в ИБ нет ошибок в регистре "ЦеныНоменклатуры", когда одна характеристика может быть по нескольким номенклатурам
2. В результате запроса может быть очень большая выборка данных - кода лишняя свёртка может быть неоправданной!
3. Не нужно думать о том, что архитектура регистра "ЦеныНоменклатуры" в будущем может поменяться - скажем, появятся ещё измерения аналитики - впрочем, тут всё не однозначно - ведь изменения архитектуры - могут быть разными - и такими, что директивой "РАЗРЕШЕНО" не отделаешься - а скорее даже замаскируешь более серьёзную проблему!
Но - это вообще уже общая проблема к формированию кода запросов в 1С Предприятие 8 - всё устарело и очень примитивно!
Но - это, уже скорее, вопросы к строкам 13 и 15, чем к 5.
Ну и, уточнили, что же нужно от кандидата - простой "код ревью" или "глубокий разбор с учётом всех возможных нюансов и контекстов"
Вообще-то как раз делает ооочень плохое: в общем случае результат запроса будет некорректным, но выявить это тестовым путём (на 2-3 позициях) будет нереально. Из головы можно легко сгенерировать тестовые данные, на которых результат будет неверным.
Директива "Разрешённые" действует на всю выборку (она здесь одна), насколько мне не изменяет память - RLS для виртуальных таблиц применяется на результат виртуальной таблицы регистра - т.е. при наличии директивы "РАЗРЕШЁННЫЕ" в нём уже будут только разрешённые записи.
ВОЗМОЖНО ИМЕННО ТУТ Я НЕ ПРАВ И ЭТО РУШИТ ВСЕ ДАЛЬНЕЙШИЕ РАССУЖДЕНИЯ!
РегистрНакопления.ВыручкаИСебестоимостьПродаж
РегистрСведений.ЦеныНоменклатуры
Имеют не пересекающиеся условия ограничений RLS в самих регистрах
По справочникам они пересекаются только по "Номенклатура" и "Характеристики" (там нет RLS на чтение, а если и было бы - то при отсутствие разрешения - то ссылки внутри запросов всё-равно были бы верными - это не нарушило бы логику (строки с такими ссылками отфильтровались бы уже при возврате результата).
Итого - если будет какой-то запрет на доступ к записям "РегистрНакопления.ВыручкаИСебестоимостьПродаж" - то строк не будет, и по ним не будет и цен (т.к. левое соединение)
Если будет запрет на доступ к записям
РегистрСведений.ЦеныНоменклатуры
То строк не будет - значит - по ним не будет цен
Но вот тут будет нюанс
Исходно в запросе такое условие
ГДЕ
ЦеныНоменклатурыСрезПоследних.Номенклатура В(&ГруппаНоменклатуры) //15Оно само по себе, вероятно не корректное - но тут, опять же - зависит от логики (а о ней данных нет)
Есть вероятность противоречия с
ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.ЦеныНоменклатуры.СрезПоследних(&ДатаОкончания, ВидЦены = &ВидЦены) КАК ЦеныНоменклатурыСрезПоследних
ПО ВыручкаИСебестоимостьПродажОбороты.АналитикаУчетаНоменклатуры.Характеристика = ЦеныНоменклатурыСрезПоследних.Характеристика //13И тут даже не дело в том, что соединение идёт по "Характеристике" - с точки зрения логики - это не проблема!
"Противоречие" тут только между "ЛЕВОЕ СОЕДИГНЕНИЕ РегистрСведений.ЦеныНоменклатуры" и "ГДЕ ЦеныНоменклатурыСрезПоследних."
И его разрешение - напрямую зависит от требуемой логики (которая не указана)
1. Либо в результат должны попадать данные выручки только с доступными/установленными ценами (0 - считается) - тогда вместо "ЛЕВОГО" было бы лучше использовать "ВНУТРЕННЕЕ СОЕДИНЕНИЕ", но, в целом - для логики это не принципиально (в данном примере)!
2. Либо в результат должны попадать все данные выручки (по отбору), а сумма по виду цен должна считаться только в когда цена доступна (оставим в покое отличия значений NULL и 0 - так как в данном примере это не принципиально) - тогда у нужно исправить условие "ГДЕ" на "ВыручкаИСебестоимостьПродажОбороты.АналитикаУчетаНоменклатуры.Номенклатура В(&ГруппаНоменклатуры)" - это уже будет принципиально!
Оставим в покое пока регистр сведений ключей аналитики - осуждаем только логику!
Поэтому рассмотрение доступа имеет смысл только после внесения правки по какому-то из вышеприведённых вариантов!
Тогда, возвращаемся к вопросу о доступе
В 1. случае у нас логически требуется объединение доступа к двум регистрам - оно так и будет - в результате будут записи, доступные в обоих регистрах - т.к. с доступные данные выручки по которым доступны цены.
В 2. случае у нас логически точно нужны доступные данные выручки, а вот что там с логикой цен - пример не поясняет. Моё мнение - что надо разделять случай - когда цены не заданы и когда цены не доступны!
Вот, только я не знаю простых путей, как это сделать в 1С - так или иначе в обычных запросах - что незаданные цены, что отсечёные по RLS - возвращаться не будут (а снятие директивы РАЗРЕШЕННЫЕ - только во втором случае сгенерирует ошибку доступа).
Решение - только выполнить выборку цен в с установкой привилегированного режима - и соединить её с выборкой без с действующим RLS - тогда можно найти отсекаемые RLS записи - цены - и, например, по ним отдельно сформировать вспомогательную врем. таблицу с аналитикой ключа соединения - а итоговой выборке - соединиться с ней - и, скажем, выводить вместо суммы текст "<Нет доступа бла бла бла>"
В чуть более простом виде можно было бы просто определять только сам факт ограничения доступа в выборке - и лишь отдельно сообщать - что по некоторым записям, где нет суммы - вероятно нет доступа , а не отсутствие заданной цены.
В общем - тут многое зависит от требуемой логики! А она не ясна в ни в постановке задачи, ни в, скажем, через анализ идентификаторов в самом коде!
Вот у меня нет актуального опыта по реальным задачам с RLS - и мне трудно самостоятельно склониться к тому или иному решению, и варианту логики!
Но, лично я бы остановился на варианте 2. - т.е. выводим всю выручку - без учета ограничений цен - т.е. когда цена не задана и не доступна - выводим ноль - тут сам вывод таких строк должен насторожить пользователя (чем их отсутствие) - а вывод тут явно для пользователя (скорее всего так показан отчёт - через "сообщить").
А, вот, если мы уберём "РАЗРЕШЕННЫЕ" - то в лоб, просто получим ошибку нарушения прав доступа! Что - по сути - неработоспособный алгоритм!
Ну или я тут совсем заблуждаюсь - тогда дайте пруф!
Вот условия в "ГДЕ" искажают результат?
А соединения таблиц (любые) - могут искажать результат?
А выдача результата отчёта вместо появления ошибки - это искажение результата?
Да - в опросах ограничения доступа много нюансов именно по части постановки задачи.
Вот об этом я в этой тем уже много раз писал - не ясны требования - от того и исправления могут быть совершенно различны - вот и уже написал тут в комментариях - тут придраться к необходимости исправления и самому варианту исправления можно почти в любой строке
Адрес | Товар | Цена | Колво
Адрес1 | Товар1 | 200 | 3
Адрес1 | Товар1 | 150 | 4
Адрес1 | Товар1 | 200 | 1то суммы будут такие:
Адрес1 | Товар1 | 600
Адрес1 | Товар1 | 600
Адрес1 | Товар1 | 200Если же добавить РАЗЛИЧНЫЕ, то одинаковые строки схлопнутся:
Адрес1 | Товар1 | 600
Адрес1 | Товар1 | 200и это будет неправильным результатом.
Вопрос группировки с итогами мы здесь не рассматриваем.
Безусловно "РАЗЛИЧЕНЫЕ" - может искажать результат, и применение данной директивы, вообще, не так часто уместно.
В указанном примере автора, на самом деле - есть более явные ошибки - правильное исправление которых ведёт за собой снятие любой потребности в данной директиве - а если её оставить, после данных исправлений, то она уже не будет искажать результат - но, будет несколько снижать его производительность (это снижение порой может быть относительно заметным, но очень редко бывает очень существенным - обычно, в таких случаях есть куда более серьёзные ошибки в архитектуре запроса или данных) - в любом случае, она будет лишней
На своей практике, я крайне редко встречал реальную потребность в применении данной директивы (кроме одного явного паттерна*). Чаще всего нужна какая-либо агрегация.
* - Эта директива частенько бывает нужна в части запросов условий "ГДЕ" (не только "ГДЕ", любых условий): "ГДЕ Чтото В (ВЫБРАТЬ РАЗЛИЧНЫЕ ЧтоТо из Чегото)" - такие конструкции, хоть и не являются самыми оптимальными, но в целом, современные СУБД вполне умеют достаточно хорошо их оптимизировать (были бы подходящие индексы с источнике "Чегото") на больших таблицах (мелкие и так прекрасно отработают) - но это не касается 1С - везде, где реально обработкой будет заниматься платформа - она не умеет это эффективно оптимизировать (она вообще, почти ничего не умеет сама оптимизировать)!
Поэтому, в общем случае лучше избегать "ГДЕ Чтото В (ВЫБРАТЬ РАЗЛИЧНЫЕ ЧтоТо из Чегото)" (просто не так часто это целесообразно - способы этого избежать могут дать меньшую производительность - поэтому этот паттерн априори нельзя считать ошибочным)
пусть я как специалист - недоросль для большинства работодателей. Но вот такой код мне аж "Глаза режет"
Я бы предпочла немного другой уровень кода.... более так сказать скрытный..
Например разница параметров в виртуальной таблице и секции где
Обращение к переменным.. МояПеременная, объект.Переменная, Элементы.Переменная ну и все такое....
А тут уж очень намуровано.. но разве что только если все 100% ошибок разом требовать)))
Не могу согласиться. Этот текст - обладает вескими достоинствами:
1) Короткий
2) Быстрый
3) Самодостаточный. Каждая неточность (ошибка) поясняется самим текстом или ИТС.
4) Дает оценку кандидата по шкале от 0 до 20.
Не каждый ребенок найдет здесь 20 неточностей (ошибок), да ?
Поделитесь своим рецептом, как проводите собеседования ?
"Мне часто приходится участвовать в собеседованиях"
Чет тут не сходится.
Но это путь в никуда. Только оценка опыта работы. Даже если он все проекты сделал с ЧатГПТ и пленным индусом, но сделал же.
ТЗ = РезультатЗапроса.Выгрузить(); //23
Для Каждого СтрокаДанных ИЗ ТЗ Цикл
Сообщить( " " + СтрокаДанных.АдресДоставки + " " + СтрокаДанных.Номенклатура + " " + СтрокаДанных.СуммаОборот ); //27
КонецЦикла;
Конкретно в данном примере "Выгрузить" абсолютно не уместно!
А насчёт типовых - если бы вы знали, как часто я раньше говорил WTF смотря на этот код! Увы - типовые - далеко не эталон качественного кода! Сейчас, я уже смерился, и даже стал писать код - похожий на типовой - ибо - просто что-то лучшее - никому не нужно - особенно на фоне такого типового кода - который затмит любую "красоту" - да и сложно вписывать что-то красивое - во структуре чего-то уродского - не трогая эту структуру!
Тем более что выборка вроде выбирает данные построчно, а выгрузка вешает сразу всю память.. хотя могу и ошибаться. Поэтому я бы к выгрузке прибегала бы только в крайнем случае)
На самом деле, в большинстве случаев (я бы сказал в 60%, а в типовом подходе к программированию - свыше 85% без каких-либо явных изменений в подходе) - Выбрать.Следующий() будет предпочтительнее - вопрос в реальном выигрыше будет динамическим и его эффективность, скорее всего в 80-90% будет незначительной. Но будет где-то как минимум около 10% где это будет реально важно!
Поэтому 1С по стандарту настывает на повсеместном применении Выбрать.Следующий(). А Выгрузить() - только там, где это реально нужно (ну или заведомо выборка будет очень маленькая с гарантией отсутствия бурного роста)!
На самом деле - я бы рекомендовал почти всегда создавать запрос через "конструктор с обработкой" - он сразу сформирует и обход запроса (в т.ч. "иерархического", т.е. с Итогами) с применением Выбрать.Следующий() - что очень удобно - т.е. это уже заметная экономия времени и нервов программиста!
Так что данный вопрос можно считать исчерпанным!
Но....
Лично я бы больше отдавал предпочтения именно ТаблицеЗначений и Выгрузить. И.... в типовом коде, реально часто именно такой подход. Причём на входе может быть и Выбрать.Следующий() - а потом наполняется ТаблицаЗначений (чуть реже - в ДеревоЗначений).
Почему?
Потому что в 1С Предприятие 8 - ТаблицаЗначений - это эдакая универсальная коллекция (да ещё и с динамической структурой) объектов данных (строки). И нужно это что бы не только получить данные из выборки запроса - но и сформировать совмещённые данные в т.ч. с постобработкой - т.е. данные в типовых 1С8 в большинстве случаев сильно дообрабатываются в объектном режиме на сервере! И проссходит это в ТаблицаЗначений, где ещё и колонки могут расширяться уже после заполнения (хотя... может сейчас в типовых этогго стабо меньше?); а сама таблица так же может несколько раз копироваться! И, порой, затем, подставляться как параметр для очередного запроса (для формирования временной таблицы)!
ИМХО - это тихий ужас! Но это реальность!
Более того - Вы думаете в типовых как-то позаботятся о больших выборках... НЕТ! Там, как раз считают, что напиши они Выбрать.Следующий() вместо Выгрузить() - и всё уже будет зашибись! А в итоге так и будут формировать и большие таблицы значений, и большие наборы записей регистров.... Даже в ERP2, кажется, так ничего и не сделали для порционной обработки данных!
И, думаете, Вы, вот так сами сможете от этого всего отказаться - и писать правильно? НЕ-А - не сможете! Так как платформа 1С Предприятие 8 и БСП категорически этому не буду содействовать!
Я Вам так скажу - для действительно эффективной обработке данных на стороне сервера - в 1С Предприятие (видимо уже не 8.x) категорически не хватает таких современных паттернов как:
1. Обработка данных на стороне СУБД (в тех возможностях, которые даёт расширенный ЯП управления данными в СУБД) - пока в 1С завезли только добавление данных во временные таблицы без выгрузки в объектную модель - вещь очень полезная, но одной её недостаточно, и в типовых она пока не используется!
2. Поточная, вернее даже конвейерная, работа с данными - когда можно вообще не заморачиваться насчёт разделения данных на порции - а просто создавать, скорее декларативным путём, цепочку фильтрации и обработки данных (сами алгоритмы обработки - не обязаны быть декларативными) - а платформа сама будет определять порции данных для буферизации! Отчасти - некоторую эмуляцию можно и на текущей платформе организовать - уже было бы хорошо - но это целый серьёзный фреймворк-библиотека!
3. Нужно применение актуальных паттернов проектирования для ООП и Функционального программирования (в идеале - АОП тоже - но это отдельная тема; в идеале - и со статической типизацией - но это не обязательно, хотя могло бы сильно повысить производительность, особенно с применением макропрограммирования и статической м динамической кодогенерации - но это всё тоже другие темы). Чтобы можно было более эффективно обрабатывать поточную обработку данных, с их абстрагированием и отрывом от контекста.
4. Простая многопоточная обработка данных (явная и неявная - когда код цепочки обработки изначально пишется так, что ориентирован на многопоточность, без явного декларирования этой многопоточности) - и я не про длительные операции и фоновые задания (хотя не обязательно и про честную многопоточную параллельность). Хотя, отчасти, и библиотеками, ко-что, можно было бы надстроить и над 1С Предприятие 8 на фоновых и регламентных заданиях - скорее уже, например по модели отложенного проведения - когда первичное проведение лишь формирует базовую структуру проведения - а уже она дальше обрабатывается в отдельных фоновых процессах. Аналогично и для сложных отчётов/обработок - когда одного запроса будет мало!
5. И вообще. Нужен общий декларативный подход определения процессов какой-либо обработки данных. Чтобы единообразно (но возможно разрозненно) сначала декларировать все требования к данным + все необходимые процессы обработки этих данных (изначально - порционные). А уже платформа - пущай сама собирает из этой декларации итоговый код оптимальной выборки данных и его оптимальной обработки - порциями и с минимальным числом циклов! Более того - по возможности, оставляя данные прям на стороне СУБД, манипулируя ими, по возможности там же! И оттуда же - возможности - формируя движения по регистрам и иные записи в БД - без лишних перетаскиваний данных на сторону сервера приложений!
Но да - какие-то процессы могут оставаться на стороне сервера приложений - и для них могут порционно выгружаться данные из временных таблиц, а потом, так же порционно, при необходимости, загружаться, в т.ч. не целиком - а только по изменившимся строкам и колонкам! А для самого кода - это всё должно быть абстрактно - он не должен знать (заботиться, узнать - конечно, может) с чем он работает - с выборкой из базы данных, (в т.ч. временной таблицы), или, скажем, с ТаблицаЗначений (или иной коллекцией данных, хранимых в объектной модели)!
6. А на закуску! Код вообще должен быть не просто более декларативным - но и более абстрактным!
Зачастую, алгоритм вообще не должен много знать о реальной архитектуре, условно, метаданных. А работать с абстрактными кирпичиками. Условно "соединяя" их друг с другом разными операциями или накладывая на них разные условия - требования! Применяя и разные методики приведения структуры/представления одних кирпичиков к другим! А сами кирпичики - тоже, вполне заранее готовы быть к различным взаимодействиям друг с другом - это заранее в них должно быть декларативно, по возможности, настроено!
Банально хотя бы источников данных (условно - виртуальных таблиц в широком смысле), которые можно было бы кастомно определять в конфигурации (и в коде тоже было бы неплохо) + группы полей (просто инфо-структуры) которые можно было бы легко использовать вместе с источниками данных + поддержка ряда основных операций над ними - и уже было бы счастье! И да - при желании - это всё можно было бы построить и на 1С Предприятие 8
Но.... это 100% меняет всю архитектуру обработки данных в 1С Предприятие. Всё что нарабатывали десятилетиям - вылетает в трубу - ибо это всё зло и давно устарело!
Я не стал добавлять пункт про возможное использование в //27 функции ПодставитьПараметрыВСтроку (на мой взгляд, это вкусовщина и здесь особо лучше не станет), но добавил пункт про отступы строк кода внутри функции (хотя, возможно это просто проблемы движка Инфостарта).
Так же ничего не отметил про ВЫБРАТЬ РАЗРЕШЕННЫЕ, т. к. они тут, похоже, к месту. Хотя, в рамках дискуссии можно было бы поинтересоваться постановкой задачи: корректно ли будет если пользователю не выйдет информация по реализациям, которые ему нельзя видеть.
Какие 20 пунктов у автора я не знаю. Допускаю, что может какие-то пункты свёрнуты в 1. Но нет желания списывать свои SM ради удовлетворения любопытства.
Автору могу продать свой список :-)
В реальности же если на код-ревью попадётся такой кусок кода - это явная некомпетентность коллеги и смысла исправлять его и поддерживать я не вижу. Более того, это некомпетентность службы найма который такого человека на работу взял и его непосредственного руководителя, а возможно и руководителя этого руководителя.
Если же вы на серьёзной мине заявите что с таким кодом действительно придётся работать - это вопрос а стоит ли вообще к вам идти? Предлагаю автору вместо этого обсуждать реальные задачи, а не выдуманные.
А померяться кодоводством - это на проект , там хоть открытые рейтинги есть.
Считаете, что в тестовом задании должна быть одна ошибка, принят-не принят ?
Вы когда-нибудь нанимали людей для компании? Разве вас рекрутер не спрашивал какими вопросами отсеять неподходящих людей?
Просто пытаюсь придумать, зачем задавать вопрос про красно-черное дерево 1С-негу. Не могу придумать.
Мне много разных вопросов задавали. Например, про нормальные формы. И когда я в общем-то ответил, то спросил, сколько человек вообще ответили на этот вопрос. Мне сказали, что НОЛЬ. Но в конторе кто-то уже работал. Так зачем?
Я куда проще подхожу к найму и ориентируюсь на два параметра: опыт и пару кейсов, с которыми человек реально встречался. Про опыт соврать не сложно, но и проверить просто - трудовая книжка. Про кейсы соврать сложно.
К чему это я? Ну примерно к тому, что есть неплохо теоретически подкованный народ, который вполне расскажет туманное определение чего угодно, но не сможет выполнять свою работу. Так зачем они мне все нужны?
я несколько раз сталкивался с ситуацией когда уже вышел на работу и неделю , десять дней отработал, и тут мне звонят радостные потенциальные наниматели, о которых я уже и забыл, с известием что "вы прошли все проверки и мы готовы заключить ....".
Меня тут немного коротнуло от: В мешке 100 кг огурцов. Влажность огурцов 99%. Огурцы подсушили, и теперь влажность составляет уже 98% их веса. Сколько теперь весят огурцы? ответ: Мв / (Мс + Мв) = Вп; x / (1+x) = 0.98; x = 0.98 + 0.98x; 2x=98; x=49
По логике:
100 - 99%
х - 98%
100*98/99 = 98,989. округляем: 98,99
Вы можете заказать платную консультацию или разработку у автора. Будет создан приватный заказ на «Бирже заказов» для автора.
№ 2293559
Создание 30.01.25 12:00
Обновление 09.05.25 11:20
Просмотры 9616
Загрузки 43
Рейтинг
4
Комментарии 115
Код открыт Да
Рубрики Управление персоналом (HRM)
Кому Разработчик
Тип файла Документация (pdf, docx, ...)
Платформа 1С:Предприятие 8
Конфигурация Универсальные
Операционная система Не имеет значения
Страна Не имеет значения
Отрасль Не имеет значения
Налоги Не имеет значения
Вид учета Не имеет значения
Доступ к файлу Абонемент ($m)
