← На главную

В процессе освоения конфигураций 1С для учета заработной платы (ЗУП, ЗКГУ или зарплатные модули в ERP и КА) у многих пользователей и разработчиков возникает закономерный вопрос: почему цепочка действий выстроена именно так? Традиционный алгоритм — создать Физическое лицо, затем создать Сотрудника и только после этого оформить документ Прием на работу — кажется избыточным. Давайте разберем логику этой архитектуры, выясним технические и методологические причины такого решения и рассмотрим способы упрощения этой процедуры.

Различие понятий: Физическое лицо vs Сотрудник

Первое, что нам необходимо усвоить — это разница между «Человеком» и «Контрактом». В терминах 1С Физическое лицо — это реальный человек, обладающий неизменными персональными данными (ФИО, СНИЛС, ИНН, дата рождения, паспортные данные). Эти данные не зависят от того, работает он в компании или нет.

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

1. Физическое лицо остается тем же самым.
2. Сотрудников будет два — один «архивный» по старому договору и один новый.

Это разделение критически важно для того, чтобы история стажа, расчет среднего заработка и остатки отпусков по первому периоду работы не перемешивались со вторым периодом.

Техническая необходимость: Сотрудник как измерение регистров

Проанализируем техническую сторону вопроса. В зарплатных конфигурациях 1С огромное количество регистров (накопления и сведений) используют справочник Сотрудники в качестве основного измерения. Это касается расчетов зарплаты, учета рабочего времени, остатков отпусков и взаиморасчетов.

Когда мы создаем документ Прием на работу, он должен сделать записи (движения) по этим регистрам. Для этого системе нужна уникальная ссылка на объект, по которому будет вестись учет. Если бы в документе выбиралось только Физическое лицо, система не смогла бы однозначно определить, к какому именно трудовому договору относится запись, если человек работает в компании одновременно на нескольких позициях (например, по основному месту и по внутреннему совместительству).

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

Почему нельзя создавать сотрудника «автоматом» при проведении приема?

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

1. Интерактивность данных: В карточке сотрудника часто хранятся данные, которые нужны еще до проведения приказа (например, лицевые счета для выплаты зарплаты или сведения о праве на льготы). Если объекта в базе нет, эти данные некуда записывать.
2. Ссылочная целостность: Если документ будет помечен на удаление или не проведен, в базе останется «повисший» элемент справочника или возникнет путаница. В 1С принята парадигма, где мастер-данные (справочники) первичны, а документы (регистраторы событий) вторичны.
3. КЭДО (Кадровый электронный документооборот): Современные системы требуют создания черновика трудового договора для отправки сотруднику на подпись еще до того, как будет издан приказ о приеме (Т-1). Создание объекта Сотрудник позволяет инициировать этот процесс заранее.

Упрощение работы: Помощники и интерфейсные решения

В современных версиях программ (например, 1С:ЗУП 3.1) разработчики реализовали «бесшовный» механизм, который скрывает сложность архитектуры от пользователя. Рассмотрим, как это работает на практике.

Вместо того чтобы заходить в три разных места, рекомендуется использовать Помощник оформления приема на работу. Проанализируем алгоритм работы через справочник Сотрудники:

1. Мы нажимаем кнопку «Создать» непосредственно в списке сотрудников.
2. Вводим ФИО человека. Система автоматически проверяет, нет ли уже такого Физического лица в базе (по ИНН или СНИЛС).
3. Если человек найден, система «подцепляет» его, если нет — создает новое Физическое лицо в фоновом режиме.
4. Прямо из формы создания сотрудника доступна ссылка «Оформить прием на работу».

Такой подход делает процесс интуитивно понятным: пользователь работает с одной «анкетой», а система сама распределяет данные по справочникам и создает документ-основание.

Может ли человек быть сотрудником без приема на работу?

Выясним, возможна ли ситуация существования сотрудника в базе без оформленного документа приема. Формально — да, элемент справочника может быть создан. Однако с точки зрения программы он будет считаться «не принятым». Это означает, что:

• По нему не будет начисляться зарплата.
• Он не будет попадать в большинство кадровых отчетов.
• У него не будет стажа и прав на отпуск.

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

Резюме

Мы выяснили, что текущая схема «Физлицо -> Сотрудник -> Прием на работу» не является ошибкой или «отрывом от реальности». Это продуманная архитектура, позволяющая:

• Корректно вести учет внутреннего и внешнего совместительства.
• Хранить чистую историю по каждому трудовому договору одного и того же человека.
• Обеспечивать высокую производительность системы при расчете зарплаты за счет использования уникальных ссылок на трудовые контракты (сотрудников) в регистрах.

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