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