В практике разработки на платформе 1С:Предприятие 8 часто возникают задачи, которые кажутся логичными с точки зрения пользователя, но входят в противоречие с фундаментальными принципами бухгалтерского учета. Одной из таких задач является попытка получить начальные или конечные остатки по счету в разрезе корреспондирующих счетов (например, по 20 счету в разрезе тех счетов, с которых пришли затраты). Рассмотрим подробно, почему стандартные отчеты этого не делают, и как можно подойти к решению этой задачи, если заказчик настаивает на ее выполнении.
Для начала проанализируем ситуацию с точки зрения теории бухгалтерского учета. В системе двойной записи счет представляет собой своего рода «бассейн». Обороты — это потоки воды, втекающие из одних источников (корсчетов) и вытекающие в другие. Когда ресурсы (деньги, материалы, затраты) попадают на счет, они обезличиваются.
Рассмотрим классический пример, который часто приводят опытные методологи: касса предприятия (счет 50). В течение дня в кассу поступили деньги от 100 разных клиентов (счет 62). Затем из этой же кассы была выплачена зарплата (счет 70) и оплачены услуги поставщиков (счет 60). К концу дня в кассе осталась одна купюра достоинством в 1000 рублей. Можно ли сказать, от какого именно клиента эта купюра? С точки зрения учета — нет. Она просто «остаток на счете 50».
То же самое происходит с 20 счетом («Основное производство»). Когда на него списываются материалы с 10 счета, амортизация с 02 счета и зарплата с 70 счета, они формируют общую стоимость незавершенного производства. В момент, когда мы видим остаток на конец месяца, мы не можем однозначно разделить его на «кусочки», пришедшие именно с 02 или 10 счета, если только мы не ведем пообъектный учет с жесткой привязкой каждой затраты.
Проанализируем структуру хранения данных в 1С:Бухгалтерия 3.0. Виртуальная таблица РегистрБухгалтерии.Хозрасчетный.Обороты позволяет получить данные в разрезе КорСчет, так как в каждой проводке (движении) всегда есть пара Дт и Кт. Однако таблица Остатки или ОстаткиИОбороты для ресурсов остатка (СуммаНачальныйОстаток, СуммаКонечныйОстаток) не содержит и не может содержать поле КорСчет.
Это связано с тем, что итоги в базе данных SQL хранятся в разрезе:
Корреспондирующий счет является атрибутом записи о движении, а не атрибутом состояния счета.
Если бизнес-задача требует жесткого отслеживания источника возникновения остатка, единственным «честным» способом будет добавление самого счета (или справочника, его дублирующего) в качестве субконто на нужный счет учета.
Разберем этот процесс по шагам:
ПланСчетовСсылка.Хозрасчетный.20.01.20.01 в данное субконто автоматически подставлялся корреспондирующий счет кредита.В этом случае система начнет хранить итоги в разрезе этого субконто, и стандартная Оборотно-сальдовая ведомость по счету покажет остатки так, как того хочет бухгалтер. Однако это потребует перепроведения документов за прошлые периоды и существенного изменения типовой конфигурации.
Рассмотрим более гибкий вариант, который не затрагивает план счетов, но позволяет собирать нужную аналитику. Мы можем создать Регистр накопления (остатки) с измерениями Счет, КорСчет, Организация и ресурсом Сумма.
Алгоритм работы будет следующим:
// При обработке проведения документа (в подписке на событие или в модуле менеджера)
// Мы анализируем набор записей регистра бухгалтерии Хозрасчетный
Для Каждого Проводка Из НаборЗаписейХозрасчетный Цикл
Если Проводка.СчетДт = ПланыСчетов.Хозрасчетный.ОсновноеПроизводство Тогда
// Формируем движение в наш вспомогательный регистр
Движение = РегистрыНакопления.ДвиженияПоКорСчетам.Добавить();
Движение.ВидДвижения = ВидДвиженияНакопления.Приход;
Движение.Период = Проводка.Период;
Движение.Счет = Проводка.СчетДт;
Движение.КорСчет = Проводка.СчетКт;
Движение.Организация = Проводка.Организация;
Движение.Сумма = Проводка.Сумма;
КонецЕсли;
// Аналогично нужно обрабатывать Расход при списании с 20 счета,
// но тут возникнет сложность с определением корсчета для списания
КонецЦикла;
Важное замечание: При списании (Расход) вам все равно придется использовать какой-то алгоритм распределения (например, FIFO), чтобы понять, «остаток какого корсчета» мы сейчас уменьшаем. Именно поэтому решение через дополнительный регистр является трудоемким и требует сложной логики при закрытии месяца.
Если заказчику достаточно «примерного» понимания того, из чего сложилось сальдо, можно разработать отчет на Системе компоновки данных (СКД), который будет использовать метод обратного восстановления.
Проанализируем логику такого отчета:
Этот метод не требует изменения структуры конфигурации, но является расчетным и может не совпадать с реальным движением активов в деталях. Тем не менее, для целей управленческого анализа это часто оказывается самым приемлемым вариантом.
Прежде чем приступать к сложной разработке, проанализируем, почему возникла такая задача. Зачастую бухгалтеры просят «остаток по корсчету», когда на самом деле им нужно:
В большинстве случаев стандартный отчет «Анализ счета» или «Анализ субконто» в сочетании с правильной настройкой аналитики (Субконто) решает проблему без «забористого» проектирования несуществующих в природе остатков по корреспонденциям.
Задача получения остатка в разрезе корсчетов является методически некорректной для классического бухучета. Если она все же должна быть решена, используйте либо дополнительные субконто (для точности), либо расчетную модель на СКД (для минимизации вмешательства в код). Помните, что в типовой конфигурации «Бухгалтерия предприятия 3.0» данные в таком разрезе физически не хранятся.