Каталог решений - Методика распределения затрат в разрезе дополнительных аналитик

В качестве предисловия.

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

Следующий вопрос: какая такая аналитика может отсутствовать, но в тоже время бывает необходимой? Перечислю ту аналитику, для получения которой данная методика была применена на практике, наверное, найдется и другая:

• получение расходов в разрезе первичных статей затрат и контрагентов (поставщиков) — данная информация используется для выгрузки в базу консолидации холдинга;
• получение расходов в разрезе активов и документов их возникновения — данная информация используется для точного учета НДС, при использовании нескольких ставок НДС с продаж (18, 0, Не облагается);
• получение активов и расходов в разрезе видов затрат для НУ (прямые, косвенные, непринимаемые (читай, постоянная разница), внереализационные, временная разница) — данная информация используется для формирования налогового учета на основе данных БУ и настроенных правил ведения НУ.

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

Теперь, по сути.

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

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

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

Как это сделать разберемся по шагам:

Шаг №1. Подготовительный.

Справедливости ради, следует отметить, что внести изменения в конфигурацию все же придется, так как результаты распределения надо где-то хранить, особенно если есть остатки НЗП, полуфабрикатов и готовой продукции. Т.е. необходимо будет создать регистр для 8, регистр или план счетов для 7.7, а также документ, который будет сохранять движения. Однако вносимые изменения не будут осложнять дальнейший процесс обновления конфигурации.

Шаг №2. С чего начать.

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

Ø            Объекты учета — это объекты, в разрезе которых ведется учет финансово-хозяйственной деятельности предприятия — совокупность счета учета и значений характеризующих его аналитических признаков, в разрезе которых производится хранение остатков на счете учета. Для объектов, которые являются конечными получателями затрат, в отличие от всех остальных, критерий хранения остатков на счете учета для аналитических признаков обязательным не является.

 Например, объект учета может быть описан как «Счет» = «20.01», «Субконто1» = «Цех №1», «Субконто2» = «Производство тумбочек». Или так «Счет» = «90.2», «Субконто1» = «Мебель».

Ø            Характеристики затрат — это совокупность аналитических признаков, в разрезе которых необходимо передавать затраты между объектами учета.

 Например, характеристики затраты могут быть описаны как совокупность какого-нибудь значения из справочника «Статьи затрат» и значения из справочника «Контрагенты».

Полученные объекты учета и характеристики затрат занесем в соответствующие таблицы значений:

ТЗ_ОбъектыУчета

 ТЗ_ХарактеристикиЗатрат

Для дальнейшей работы нам понадобятся только коды объектов и затрат, а их описание будет необходимо только для записи результатов.

Шаг №3. Заполняем исходные данные для распределения.

На данном этапе необходимо заполнить еще 2 таблицы значений, с которыми собственно и будет вестись основная работа:

ТЗ_ЗатратыКРаспределению

 Значение колонки «Сумма» формируется как «Сумма остатка на начало» + «Сумма первичных затрат за период».

— «Сумму остатка на начало» — получаем на основе анализа, созданного хранилища результатов распределения, в разрезе объектов учета и характеристик затрат;

— «Сумму первичных затрат за период» — получаем на основе анализа данных бухгалтерского учета в части движений, в которых происходит первичное накопление затрат на объектах учета в разрезе интересующих нас характеристик затрат.

ТЗ_СвязиОбъектов

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

В качестве значения для колонки «Коэффициент» устанавливаем значение кредитового оборота между объектом источником и объектом получателем.

Для корректной работы алгоритма, при наличии у объекта учета остатков, необходимо также добавить строку, в которой код источника будет равен коду получателя, а значение колонки «Коэффициент» будет равно сумме остатка на конец по данным бухгалтерского учета.

Важно! Значение колонки «Коэффициент» должно быть всегда больше 0. Ответ на вопрос, что делать с отрицательными суммами см. ниже в разделе «Подводные камни».

 Примечание. В данной статье Шаг №2 и Шаг №3 выделены как отдельные шаги, исходя из методологических соображений, т.е. для лучшего понимания. При программной реализации рационально выполнение сразу Шага №3 и уже из него выполнять Шаг №2, при появлении новых объектов учета и новых характеристик затрат.

Шаг №4. Собственно распределение.

На данном этапе необходимо организовать циклический обход строк таблицы ТЗ_ЗатратыКРаспределению. Критерием выхода из цикла будет отсутствие строк в таблице ТЗ_ЗатратыКРаспределению.

При получении очередной строки основная задача распределить имеющуюся текущую сумму между получателями текущего источника. Получателей и коэффициенты распределения получаем из ТЗ_СвязиОбъектов по значению соответствующего источника.

Результаты записываем в финальную таблицу значений, например, ТЗ_Результаты, которая может иметь следующую структуру:

Если объект получатель не является конечным получателем затрат, то дополнительно добавляем строку в ТЗ_ЗатратыКРаспределению (при наличии в ТЗ строки с «Кодом объекта» = коду объекта получателя и «Кодом затраты» = коду текущей затраты, целесообразно просто увеличивать сумму).

Шаг №5. Фиксируем результаты.

Ну, тут все просто скрещиваем ТЗ_Результаты с ТЗ_ОбъектыУчета и ТЗ_ХарактеристикиЗатрат и записываем результат в созданное нами хранилище. Вот и вся методика.

В качестве послесловия.

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

Анонсированные подводные камни.

На данный момент у меня в памяти только один, но важный. Если вспомню что-то еще, буду дописывать, а может, и Вы подскажете — тоже разберем.

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

Кто-то может возразить, что и отрицательный коэффициент не представляет особой сложности. В целом, я соглашусь, но при наличии сложных, циклических взаимосвязей и определенного набора распределяемых затрат, мне решить проблему не удалось. А что более важно — отрицательный коэффициент противоречит экономическому смыслу. Предположим, что в одном периоде Цех №1 списал на Цех №2 100 руб. затрат. В другом периоде выясняется, что было излишне списано 30 руб. => что Цех №1 в текущем периоде должен передать Цех №2 -30 руб. С точки зрения экономического смысла, данная формулировка абсурдна, так как -30 руб. в природе не существует, поэтому неоткуда взять и характеристики данной затраты.

Что делать?! Я знаю 3 варианта решения данной проблемы. Два первых варианта использовались, так как разных Заказчиков устраивала разная точность результатов.

Вариант 1. Первое, что приходит в голову, так это поменять источника и получателя местами, соответственно и знак коэффициента изменится. Дополнительно, конечно, придется где-то запомнить, что при формировании окончательных движений необходимо все вернуть обратно, ну да это не проблема. Таким образом, ситуация становится нормализуется, теперь Цех №2 должен передать Цех №1 30 руб.. Однако может возникнуть ситуация когда от Цех №2 на Цех №1 попадут затраты с такими характеристиками, которых никогда не было у Цех №1 в качестве первичных затрат. Если на это закрыть глаза, то данный вариант вполне сгодится.

Вариант 2. Данный вариант, думаю, тоже не блещет оригинальностью. Предлагается проанализировать все затраты, которые списывались с Цех №1 на Цех №2 за определенный период и распределить между ними соответствующую сумму, причем до общего распределения затрат, тем самым исключив ее из распределения. В данном случае точность отраженной информации, будет зависеть от выбранного для анализа периода — оптимальный вариант с точки зрения точности (но явно не производительности), для каждой сторнировки указывать тот период, к которому она относится. В общем же, вполне приемлемо использовать период с начала квартала или начала года до месяца, в котором проходит распределение.

Вариант 3. Перенести всю ответственность на пользователя. По сути, это Вариант 2, только пользователь все корректирует сам, на основе выведенных ему проблемных сторнировок.

P.S. Собственно алгоритм, который создан на основании данной методики заложен в обработку //sale.itcity.ru/projects/5079