При автоматизации процессов и интеграции 1С:ЗУП с другими системами часто возникает задача программного создания документов, например, для загрузки изменений зарплаты сотрудников из внешнего источника. Однако при работе с такими сложными документами, как ИзменениеОплатыТруда, разработчики сталкиваются с неочевидной проблемой: вся основная бизнес-логика по расчету и подготовке данных находится не в модуле объекта или менеджера, а в модуле формы. Попытка просто создать документ, заполнить его реквизиты и табличные части, а затем записать, скорее всего, приведет к некорректному результату. Документ не будет содержать всех необходимых вычисляемых данных и не сформирует правильных движений по регистрам.
Давайте разберемся, почему так происходит и какие существуют подходы для решения этой задачи.
Исторически в конфигурации "Зарплата и управление персоналом 3" разработчики 1С выносили значительную часть логики в модули форм. Это делалось для обеспечения высокой интерактивности и быстрого отклика интерфейса при работе пользователя: при изменении одного поля в форме сразу же пересчитываются и обновляются другие зависимые данные. Однако этот архитектурный подход создает серьезные трудности для автоматизации. Когда мы создаем документ программно на сервере (например, в рамках обработки HTTP-запроса), у нас нет контекста формы, и, соответственно, все эти полезные обработчики событий не выполняются.
Итак, перед нами стоит задача: как выполнить всю необходимую логику формы, не открывая ее интерактивно? Рассмотрим основные стратегии.
Это самый надежный, хотя и наиболее трудоемкий метод. Его суть заключается в том, чтобы "обмануть" систему, воссоздав на сервере условия, приближенные к работе формы, и выполнив скопированный из нее код. Разберем этот процесс по шагам.
Первым делом откройте в конфигураторе форму документа ИзменениеОплатыТруда и внимательно изучите ее модуль. Нас интересуют серверные процедуры и функции. Особое внимание уделите обработчикам событий:
ПриСозданииНаСервере — здесь часто происходит начальная инициализация.ПриИзменении для ключевых реквизитов (например, даты документа, вида начисления).Ваша цель — понять последовательность вызовов и то, как данные формы (ДанныеФормы) преобразуются и попадают в реквизиты объекта (Объект) перед записью.
Создайте свою обработку или общий серверный модуль, куда вы будете копировать необходимый код из модуля формы. Простого копирования будет недостаточно, код придется адаптировать.
Главная проблема в том, что в серверном коде нет объекта ЭтаФорма и ее реквизитов. Чтобы обойти это, создайте переменную типа Структура, которая будет имитировать реквизиты формы. Вы можете заполнить ее данными, которые получили из внешнего сервиса.
Как было предложено на форуме, можно создать две вспомогательные функции, которые будут переносить данные между вашим создаваемым объектом документа и этой структурой, что упростит адаптацию кода.
В скопированном коде необходимо методично заменить все обращения к элементам формы (например, ЭтаФорма.Объект, Элементы.Начисления) на обращения к вашему создаваемому документу и структуре-аналогу. Это самая кропотливая часть работы.
После адаптации кода вызовите в своей обработке нужные процедуры в той же последовательности, в которой они выполняются в форме. После выполнения всех расчетов и заполнения объекта документа его можно записывать.
Важный момент: Как справедливо заметили в обсуждении, данные формы в ЗУП-овских документах могут сильно отличаться от структуры табличных частей объекта. Например, в форме могут отображаться агрегированные данные или показатели, которые рассчитываются "на лету". Если просто заполнить табличную часть Начисления, проигнорировав всю остальную логику, документ не будет работать так, как ожидается. Поэтому эмуляция — это не просто дублирование кода, а воссоздание всего процесса подготовки данных.
Прежде чем погружаться в сложный анализ формы документа ИзменениеОплатыТруда, стоит задать себе вопрос: а нельзя ли решить мою бизнес-задачу другим, более простым документом? Зачастую ответ — да. В 1С:ЗУП есть несколько документов, которые гораздо лучше приспособлены для программной работы.
Документ "Кадровый перевод"
Это универсальный и часто рекомендуемый способ для изменения условий труда одного сотрудника. Он позволяет в рамках одного документа изменить должность, подразделение и, что самое главное, плановые начисления (включая оклад). Его объектная модель более прозрачна и легче поддается программному заполнению.
Документ "Изменение плановых начислений"
Этот документ отлично подходит для массового изменения одного или нескольких видов начислений для целой группы сотрудников. Если ваша задача — например, проиндексировать оклады всему отделу, этот документ будет идеальным выбором.
Документ "Назначение планового начисления"
Используйте его, если нужно точечно назначить новый вид начисления сотруднику или группе сотрудников (например, ввести новую надбавку).
Рекомендация: Всегда начинайте с анализа бизнес-требований. Вполне возможно, что использование одного из этих документов полностью закроет вашу потребность и сэкономит массу времени и сил на эмуляции сложной логики.
В платформе 1С существует механизм внешних обработок для заполнения табличных частей. Этот вариант был упомянут на форуме и может быть полезен в определенных сценариях. Вы можете создать внешнюю обработку, которая по определенному алгоритму (например, читая данные из файла) заполняет табличную часть документа.
Однако этот подход больше ориентирован на интерактивную работу пользователя, когда он нажимает на кнопку "Заполнить" в уже открытой форме документа. Он не решает основной проблемы — запуска всех сопутствующих расчетов и обработчиков, которые находятся в модуле формы. Поэтому для полностью автоматизированного сценария без участия пользователя этот метод, скорее всего, не подойдет.
Проблема с концентрацией логики в формах — это известная архитектурная особенность 1С:ЗУП 3. Хорошая новость в том, что фирма "1С" признает эту проблему и в последних релизах постепенно переносит бизнес-логику в общие серверные модули и модули менеджеров. Примером такого "исправления" является документ Отпуск, программная работа с которым стала значительно проще.
Однако этот процесс идет медленно, и для многих "старых" и сложных документов, включая ИзменениеОплатыТруда, по-прежнему актуальны описанные выше подходы. Таким образом, при решении задачи программного создания таких документов рекомендуем придерживаться следующего алгоритма:
Кадровый перевод, Изменение плановых начислений).Этот путь требует терпения и глубокого понимания логики конфигурации, но в итоге позволяет добиться корректной работы автоматизированных процессов.