При работе с конфигурацией 1С:Зарплата и управление персоналом (ЗУП) 3.1 многие разработчики и опытные пользователи задаются вопросом: почему регистр сведений Лицевые счета сотрудников спроектирован как непериодический? Ведь на первый взгляд кажется логичным хранить историю изменения банковских реквизитов сотрудника именно через механизм периодичности регистра, чтобы иметь возможность видеть, какой счет действовал в определенный момент времени.
Давайте подробно проанализируем эту ситуацию, разберем методические соображения фирмы «1С», технические аспекты платформы и выясним, как на самом деле устроено хранение истории в системе.
Рассмотрим основной принцип, заложенный в основу 1С:ЗУП. В этой конфигурации регистры сведений часто играют роль вспомогательных инструментов для быстрого подбора данных («кеша»), в то время как первичная информация и история ее изменений хранятся в документах-регистраторах. Проанализируем, как это работает в случае с лицевыми счетами:
Ведомость в банк. В момент формирования ведомости система обращается к регистру Лицевые счета сотрудников, подтягивает актуальный номер счета и записывает его непосредственно в табличную часть документа. Это критически важный момент: даже если через месяц вы измените номер счета в карточке сотрудника или в регистре, в старой ведомости останется тот номер, по которому фактически была произведена выплата. Это обеспечивает юридическую чистоту и неизменность отчетности за прошлые периоды.Ввод лицевых счетов и Подтверждение открытия лицевых счетов. Если нам необходимо выяснить, когда и на каком основании был изменен счет, мы должны обратиться к журналу этих документов.Разберем техническую сложность, которая возникла бы, если бы разработчики сделали регистр Лицевые счета сотрудников периодическим. В 1С:ЗУП существует такое понятие, как «Способ выплаты зарплаты» (через кассу, через зарплатный проект или на личный банковский счет). Эта настройка сама по себе является периодической и хранится в других регистрах.
Если бы лицевые счета тоже имели периодичность, системе при формировании каждой ведомости приходилось бы решать сложнейшую задачу сопоставления двух временных шкал:
Проанализируем ситуацию: сотрудник переведен на новый зарплатный проект 10-го числа, а новый лицевой счет в регистре открыт 11-го числа. При попытке сформировать ведомость на 10-е число система могла бы выдать ошибку или подобрать неверные данные из-за микро-смещений в датах. Непериодический регистр гарантирует простую логику: если сотрудник в данный момент привязан к зарплатному проекту, система берет тот счет, который указан для него в этом проекте как актуальный.
Выясним причину отсутствия истории внутри одного проекта с точки зрения банковского взаимодействия. Система спроектирована исходя из стандартов обмена данными с банками (форматы XML, DirectBank). В рамках одного действующего договора (зарплатного проекта) у сотрудника, как правило, не может быть двух одновременно работающих лицевых счетов.
Рассмотрим сценарии:
Организация, ЗарплатныйПроект, ФизическоеЛицо) позволяют хранить разные счета для разных проектов одновременно. Проблема «затирания» возникает только в том случае, если вы пытаетесь ввести второй счет на тот же самый проект, что методологически неверно.Посмотрим на ситуацию с точки зрения законодательства. Статья 136 ТК РФ гласит, что заработная плата перечисляется в «кредитную организацию, указанную в заявлении работника». Закон оперирует понятием в единственном числе. Отношение «один сотрудник — один банк/счет» является базовым для трудового права.
Хотя сотрудник может менять реквизиты хоть каждую неделю (предупредив за 15 дней), в конкретный момент времени для конкретной выплаты существует только один легитимный счет. Непериодический регистр в 1С идеально отражает это состояние «актуального выбора».
Рассмотрим часто возникающие вопросы пользователей и способы их решения без изменения типового функционала.
Если сотрудник принес реквизиты сегодня, а действовать они должны с 1-го числа следующего месяца, в типовой конфигурации рекомендуется использовать документ Ввод лицевых счетов. Однако, поскольку регистр непериодический, проведение документа сразу изменит текущий счет.
Решение: Подготовьте документ Ввод лицевых счетов, заполните его, но не проводите (или установите дату документа будущим числом). Проведите его непосредственно перед формированием первой ведомости в новом периоде. Для автоматизации этого процесса в крупных компаниях часто используют небольшие расширения, которые проводят такие документы по расписанию.
Для анализа истории не нужно искать периодичность в регистре. Проанализируем два способа получения этих данных:
Ведомость в банк с фильтром по конкретному сотруднику. Там вы увидите все счета, на которые реально уходили деньги.Ввод лицевых счетов по данному физическому лицу.Важно не путать Лицевые счета сотрудников (которые привязаны к проектам) и Банковские счета (личные счета). Для личных счетов используется справочник, связанный с физическим лицом. Там можно хранить неограниченное количество счетов, но один из них помечается как основной. Это также избавляет систему от неоднозначности при автоматическом заполнении платежных поручений.
Подведем итог нашему анализу. Отсутствие периодичности в регистре лицевых счетов — это не ошибка разработчиков, а осознанное архитектурное решение, направленное на:
История в 1С:ЗУП — это не состояние регистра, а последовательность документов. Придерживаясь этой логики, вы сможете эффективно вести учет и избегать ошибок при выплате заработной платы.