При переходе с ЗУП 2.5 на версию 3 многие разработчики сталкиваются с архитектурным шоком. В системе появилось огромное количество независимых регистров сведений, записи в которые производятся программно, без жесткой привязки к регистратору. Это усложняет отладку через стандартный поиск ссылок и заставляет тратить часы в дебагере. В этой статье мы разберем по шагам, зачем 1С пошла по этому пути, как устроена современная архитектура ЗУП 3 и какими методами нужно пользоваться, чтобы не «изобретать велосипед».
Рассмотрим главную особенность ЗУП 3. Мы привыкли, что структура метаданных (регистры, документы) — это и есть наш интерфейс работы с данными. В ЗУП 3 ситуация иная. Разработчики конфигурации реализовали концепцию «метаданных на уровне кода». Это означает, что программисту больше не нужно знать точное имя регистра и структуру его полей. Вместо этого предоставляется набор методов (API), которые гарантированно возвращают корректные данные.
Проанализируем ситуацию: структура регистров может меняться от релиза к релизу (например, разделение регистров на первичные и вторичные). Если вы напишете прямой запрос к таблице, ваше решение «сломается» при обновлении. Если же вы используете официальный программный интерфейс, 1С гарантирует работоспособность вашего кода, так как внутри методов они сами подстроят логику под новую структуру таблиц.
Выясним причину такого обилия таблиц. Основная цель — ускорение работы системы при построении отчетов и выполнении расчетов. В ЗУП 2.5 для получения должности сотрудника на определенную дату часто приходилось писать сложные запросы с использованием конструкций ВЫБОР КОГДА и соединением нескольких таблиц (периоды завершения и т.д.).
В ЗУП 3 внедрена денормализация данных. При проведении документа информация раскладывается сразу в несколько регистров в нужных разрезах. Например, существуют пары регистров:
ДанныеСостоянийСотрудников).СостоянияСотрудников).При записи в первичный регистр система автоматически пересчитывает интервалы во вторичном. Это позволяет в запросах просто накладывать условие на период, не вычисляя срезы последних программно. Это крайне эффективно для больших баз (свыше 10 000 сотрудников).
Рассмотрим подробнее, как получить данные о сотруднике (должность, подразделение, состояние), не обращаясь к регистрам напрямую. Для этого в ЗУП 3 предусмотрен мощный механизм в общем модуле КадровыйУчет.
Основной метод, который следует использовать для массового получения данных — это формирование временной таблицы. Проанализируем пример схемы работы:
// Подготавливаем описание нужных нам полей
ОписательТаблиц = КадровыйУчет.ОписательВременныхТаблиц(МенеджерВременныхТаблиц);
// Вызываем метод, который сам соберет данные из всех нужных регистров (включая интервальные)
КадровыйУчет.СоздатьВТКадровыеДанныеСотрудников(ОписательТаблиц, Истина, "Состояние,Должность,Подразделение");
Этот подход освобождает вас от необходимости знать, в каком именно регистре (КадроваяИсторияСотрудников или СостоянияСотрудников) лежат данные. Метод сам учитывает учетную политику, часовые пояса и другие нюансы.
Если вам необходимо программно изменить данные (например, при обмене со сторонними системами), категорически не рекомендуется напрямую писать наборы записей в независимые регистры. Это приведет к тому, что связанные «вторичные» регистры не обновятся, и отчеты будут показывать старую информацию.
Разберем, как это сделать правильно. Для записи кадровых движений используйте метод:
КадровыйУчет.СформироватьКадровыеДвижения(Параметры)
Для работы с учетом времени и отсутствиями следует обращаться к общему модулю УчетРабочегоВремениРасширенный. Помните, что в ЗУП 3 расчеты зачастую отделены от форм и вынесены в специальные менеджеры. Например, расчет зарплаты инициируется через МенеджерРасчетаЗарплаты.
Поскольку официальной полной документации по всем функциям типовых конфигураций может не быть под рукой, применим следующие приемы поиска нужного функционала:
ЗарплатаКадрыСоставПодчиненныхОбъектов, КадровыйУчет, УчетРабочегоВремени) и ищите методы в специально помеченных областях.Многие разработчики жалуются, что ЗУП превратилась в «черный ящик». Однако это вынужденная мера для унификации кода между ЗУП, ERP и Комплексной автоматизацией. Используется библиотека Zarkad (Зарплата и Кадры), которая должна работать одинаково во всех флагманских решениях. Помните: если вы решили доработать ЗУП 3 через расширение, старайтесь вклиниваться в логику программных методов, а не менять структуру хранения данных.
Архитектура ЗУП 3 движется в сторону абстракции от физических таблиц СУБД. Главные принципы выживания разработчика в этой среде:
КадровыйУчет.СоздатьВТКадровыеДанныеСотрудников для чтения.Такой подход, несмотря на сложность освоения, в конечном итоге делает код более устойчивым к изменениям законодательства и обновлению типовых конфигураций.