Получить данные с 1с

Обновлено: 06.07.2024

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

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

В общих модулях ЗУП есть функции для получения данных например, КадровыйУчет.КадровыеДанныеСотрудников(). Воспользуемся ими для решения задачи. Нам требуются кадровые данные сотрудников и данные по позиции штатного расписания сотрудника. Логично предположить, что функцией КадровыйУчет.КадровыеДанныеСотрудников мы вряд-ли такие данные получим. Нужно искать другие функции::


Как видно, код очень простой и компактный. Мне это решение не нравится по нескольким причинам.

  1. Не все функции для получения данных находятся в программном интерфейсе соответствующего общего модуля. Вендор не обещал обратную совместимость для служебных процедур и функций, которой как раз и является функция УправлениеШтатнымРасписанием.ДанныеПозицийШтатногоРасписания(..).
  2. К функции выше нет описания. Приходится тратить время на то, чтобы понять что она делает и что надо для ее вызова.
  3. Таким образом получается несколько коллекций с нужными значениями. Нам требуется их обработать и создать одну коллекцию.

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

Воспользуемся процедурами по созданию временной таблицы в менеджере.

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

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

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

Но и тут есть крайне досадные недостатки.

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

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

Мы собрали запрос-пустышку. А что если и тут поступить так же? Соберем пустышку :


Получим реально исполняемый запрос процедурой ЗаменитьЗапросыКПредставлениямВиртуальныхТаблиц()

Как видно выходных данных у нас немного, но запрос наш просто монстр. Да, он выполнится за одно обращение к базе но получит кучу ненужных данных. 1С-совесть спать не даст.. Полагаю, механизм замены представлений написан для отчетов, поэтому разработчики не заботились об оптимизации запроса, да и зачем? Если СКД сама это сделает. Так и поступит.

Создаем СКД программно, связываем с компоновщиком, компонуем макет.

Запрос в макете компоновки заметно похудел.

Отлично. Дальше дело вкуса. Можно вывести результат в коллекцию, можно получить выборку.

Конечно, и этот метод не идеален.

  1. Требуются дополнительные усилия по созданию СКД, тем более полностью программно.
  2. Получение макета компоновки, как правило, занимает много времени.

Однако , мне такой способ видится наиболее полезным.

Макет компоновки можно закешировать, как, тема не этой статьи, но способы оптимизации есть. Работа со схемой компоновки данных мне видится гораздо более полезной для опыта разработчика , нежели изучение дебрей ЗУП на предмет поиска способов вытащить данные. Здесь мы знаем лишь об одной функции ЗарплатаКадрыОбщиеНаборыДанных.ЗаменитьЗапросыКПредставлениямВиртуальныхТаблиц() И из нее, если нам надо, можем распутать клубок с процедурами по созданию временных таблиц. Да, эта функция тоже находится в служебном программном интерфейсе, но если разработчик ее переименует или изменит, будет проще разобраться в работе одной функции, чем искать, куда переехала СоздатьВТ из УправленияШтатнымРасписанием.

К статье прилагается обработка с примерами. Тестировалось на релизе Зарплата и управление персоналом КОРП, редакция 3.1 (3.1.14.369).

Читайте также: