В практике разработчиков и архитекторов 1С часто возникает классическая дилемма: бизнесу требуется добавить дополнительный разрез учета (например, проекты, прорабы, направления деятельности или целевые программы) на счетах бухгалтерского учета, но все доступные три субконто на нужном счете уже заняты. Типичный пример — счет 60 «Расчеты с поставщиками и подрядчиками», где аналитика жестко распределена между контрагентами, договорами и документами расчетов.
В этой статье мы подробно проанализируем, почему физическое добавление четвертого субконто в план счетов — это опасный путь, как это изменение влияет на базу данных на уровне СУБД, к каким последствиям приводит при обновлениях и какими современными безопасными альтернативами можно решить эту задачу без изменения метаданных регистра бухгалтерии.
Прежде чем принимать решение об изменении плана счетов, давайте разберем, как платформа «1С:Предприятие 8» организует хранение данных бухгалтерского учета в СУБД (MS SQL Server, PostgreSQL, IBM DB2 или Oracle). Максимальное количество субконто задается в свойствах объекта метаданных ПланСчетов. В типовых конфигурациях этот лимит равен 3.
Когда мы увеличиваем этот лимит в Конфигураторе (например, до 4), платформа выполняет глобальную реструктуризацию таблиц базы данных:
_AccRg) добавляются новые поля для хранения значений четвертого субконто (например, _Subconto4_RRef для ссылочного типа и сопутствующие поля для определения типа данных)._AccRgOpt, _AccRgCust) начинают хранить информацию в разрезе четырех аналитик. Объем сохраняемых записей итогов резко возрастает, что приводит к значительному увеличению размера базы данных.Проанализируем основные проблемы, с которыми неизбежно столкнется система и команда поддержки при добавлении четвертой аналитики напрямую в план счетов.
1. Катастрофическое падение производительности.
Каждая операция проведения документа, затрагивающего измененный регистр бухгалтерии, начнет требовать больше времени на запись данных и обновление индексов. При высокой интенсивности работы пользователей (особенно в моменты массового проведения документов или закрытия месяца) СУБД начнет генерировать избыточные ожидания на блокировках таблиц (блокировки СУБД), что может привести к полной остановке совместной работы.
2. Сложности при обновлении конфигурации.
При выходе очередного обновления от фирмы «1С» конфигурация поставщика будет содержать исходную структуру плана счетов с ограничением в 3 субконто. При сравнении и объединении конфигураций возникнет конфликт. В худших сценариях попытка обновиться «напрямую» может привести к критической ошибке реорганизации СУБД и даже потере данных в колонках четвертого субконто. Обновление такой базы потребует высокой квалификации программиста и значительных временных затрат на ручной контроль сопоставления объектов.
3. Несовместимость со стандартными отчетами.
Стандартные бухгалтерские отчеты (Оборотно-сальдовая ведомость, Анализ счета, Карточка счета и др.) в старых версиях платформы или сильно кастомизированных конфигурациях могут быть жестко завязаны на трехмерную аналитику. Четвертое субконто в них либо вообще не будет выводиться, либо потребует полной переработки макетов и схем компоновки данных (СКД) этих отчетов.
Если бизнес-требования категорически настаивают на добавлении четвертой аналитики именно в регистр бухгалтерии, и другие пути невозможны, существует технический компромисс. Мы можем настроить четвертое субконто с признаком «Только обороты».
Давайте разберем, почему это существенно облегчает жизнь СУБД:
Минус решения: Вы сможете построить отчет и увидеть, сколько оборотов (дебетовых или кредитовых) прошло по данному проекту или прорабу за период, но вы никогда не сможете получить классическое сальдо (остаток долга или материалов) по этой аналитике на конкретную дату.
Рассмотрим по шагам наиболее эффективные и безопасные способы реализации дополнительного аналитического учета, которые не затрагивают структуру плана счетов.
Если нам необходимо связать взаиморасчеты (счет 60, 62, 76) с проектами, и при этом в рамках одного договора с контрагентом все операции ведутся строго по одному проекту, мы можем использовать встроенный функционал Библиотеки Стандартных Подсистем (БСП) — «Дополнительные реквизиты и сведения».
Проанализируем этот процесс:
ДоговорыКонтрагентов новый реквизит «Проект» с типом ссылки на наш справочник проектов.Договор.Проект (или Договор.ДополнительныйРеквизит.Проект).В результате мы получаем полноценный отчет в разрезе проектов без изменения кода конфигурации, без рисков при обновлениях и без снижения производительности СУБД.
Если у нас по одному «физическому» договору с контрагентом ведутся работы по нескольким проектам, то вместо добавления субконто мы можем применить административно-методологическое решение: разделить договоры в системе.
Вместо одного элемента Договор №125 мы создаем в справочнике несколько элементов:
Договор №125 (Проект А)Договор №125 (Проект Б)При таком подходе аналитика «Договор», которая уже является вторым стандартным субконто на счетах расчетов, автоматически выполняет роль проекта. Все стандартные отчеты и механизмы закрытия месяца работают в штатном режиме.
Если требуется вести сложный учет (например, передача материалов давальцу в разрезе договоров и прорабов на счете 10.07, как в сообщении 12), и субконто заняты, наиболее профессиональным решением является создание отдельного регистра накопления или сведений.
Давайте разберем, как реализовать этот подход на практике. Мы создаем регистр накопления УчетМатериаловПоПрорабам со следующей структурой:
Контрагент (СправочникСсылка.Контрагенты), Договор (СправочникСсылка.ДоговорыКонтрагентов), Прораб (СправочникСсылка.ФизическиеЛица), Номенклатура (СправочникСсылка.Номенклатура).Количество (Число), Сумма (Число).При проведении документов, которые списывают или передают материалы (например, «Передача товаров»), мы наряду с бухгалтерскими проводками делаем записи в наш новый регистр. Посмотрим на пример кода в модуле проведения документа:
Процедура ОбработкаПроведения(Отказ, РежимПроведения)
// 1. Стандартные движения по регистру бухгалтерии
// ... (код формирования проводок по счету 10.07)
// 2. Движения по нашему кастомному регистру "сбоку"
Движения.УчетМатериаловПоПрорабам.Записывать = Истина;
Для Каждого СтрокаТЧ Из Товары Цикл
Движение = Движения.УчетМатериаловПоПрорабам.Добавить();
Движение.ВидДвижения = ВидДвиженияНакопления.Приход;
Движение.Период = Дата;
// Заполняем измерения из реквизитов документа
Движение.Контрагент = Контрагент;
Движение.Договор = ДоговорКонтрагента;
Движение.Прораб = СтрокаТЧ.Прораб; // Реквизит табличной части или шапки
Движение.Номенклатура = СтрокаТЧ.Номенклатура;
// Заполняем ресурсы
Движение.Количество = СтрокаТЧ.Количество;
Движение.Сумма = СтрокаТЧ.Сумма;
КонецЦикла;
КонецПроцедуры
Для вывода отчетности мы создаем внешний отчет на базе Системы Компоновки Данных (СКД), который берет данные из таблицы остатков и оборотов нашего регистра УчетМатериаловПоПрорабам. Этот отчет будет формироваться мгновенно, не нагружая тяжелый регистр бухгалтерии, и полностью решит задачу контроля выданных прорабам материалов.
Проанализируем плюсы и минусы каждого подхода в виде структуры:
Если перед вами стоит задача расширить аналитику учета, настоятельно рекомендуем избегать изменения максимального количества видов субконто на плане счетов. Использование механизмов свойств договоров или создание параллельных регистров накопления — это профессиональный стандарт разработки в системе «1С:Предприятие 8». Эти методы гарантируют стабильность вашей базы данных, высокую скорость работы пользователей и легкое обновление конфигурации в будущем.