gifts2017

Методика распределения затрат в разрезе дополнительных аналитик

Опубликовал Денис Маршалкин (Demarsh) в раздел Программирование - Теория программирования

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Код объекта

Счет учета

Субконто1

Субконто2

...

СубконтоN

 

 

 

 

 

 

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

Код затраты

Характеристика1

...

ХарактеристикаN

 

 

 

 

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

 

Шаг №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. Собственно алгоритм, который создан на основании данной методики заложен в обработку http://infostart.ru/projects/5079

См. также

Подписаться Добавить вознаграждение

Комментарии

1. Александр Рытов (Арчибальд) 21.07.09 08:46
Данное направление еще ждет своих разработчиков. Есть кое-что готовое, например, http://www.ec-network.ru/index.php?option=com_frontpage&Itemid=1
Однако до завершеня работа далека. Кроме этого, математическая суть расчета себестоимости с помощью графа затрат - это решение системы линейных уравнений с плохо детерминированной матрицей (т.е. не решаемой, скажем, в Екселе). В статье ситуация отличается тем, что незавершенка во вспомогательном цехе считается внутренним оборотом, что не меняет модели (просто вместо свободных членов применяются коэффициенты к "переменной" 1). Но есть ли бухгалтерский смысл (хозяйственное содержание) решения системы?
2. Александр Рытов (Арчибальд) 21.07.09 09:00
Реализация похожей модели в Бух 7.7 потребовала только добавления трех документов: "НезавершенкаВспомогательного", "ОтчетЦеха" и "Себестоимость". Последний как раз и служит для хранения результатов решения системы линейных уравнений (решает систему в процессе проведения). Сопровождаемость/обновляемость, как правильно указывается в статье, при этом сохраняется (см. http://infostart.ru/blogs/1040/ )
3. Игорь Исхаков (Ish_2) 21.07.09 09:20
(2)" решает систему в процессе проведения"

Извиняюсь , каким методом ? Проверяется вырожденность матрицы (detA=0) ?
Возможны ли плохо обусловленные матрицы ?
4. Александр Рытов (Арчибальд) 21.07.09 13:07
(3) Метод Гаусса (приведение к верхнетреугольному виду). Это как раз для плохо обусловленных матриц. И пузырьковая сортировка строк.
А от вырожденности спасают два обстоятельства. Во-первых, мы же имеем дело с приближенным решением (руб. коп.), что снижает вероятность зануления детерминанта. Во-вторых, мы работаем не с самой себестоимостью, а с отклонениями от плановой, т.е. если не удается вычислить отклонение, то оно считается нулевым и в расчетах не участвует.
5. Денис Маршалкин (Demarsh) 21.07.09 13:25
(1) Что ж, я ждал, что раньше или позже эта ссылка всплывет. В таком случае придется сказать, что я стоял у истоков, приведенной по ссылке компании и программного продукта. Правильнее сказать, что как программист, именно я создал систему распределения затрат на платформе 7.7, которая использовала внешнюю библиотеку (по решению систем линейных уравнений), которая в свою очередь используется в вышеупомянутом продукте. К созданию данного продукта на платформе 8.1, я имею лишь косвенное отношение, однако понимание того как он работает мне очень хорошо знакомо.
К созданию собственного алгоритма распределения затрат, меня подтолкнула мизерная проблема, которая может возникать при использовании численных методов решения системы линейных уравнений. А именно возможность зависания копеек разного знака после распределения. Происходит это потому, что решение системы линейный уравнений идет относительно тарифов, т.е. вычисляется стоимость одной единицы "Коэффициента распределения". Например, если в качестве коэффициентов используется количество переданной электроэнергии, то решая систему мы ищем стоимость одного квт/час. Соответственно сумма проводки вычисляется как значение Тарифа*Коэффициент распределения, а так как сумма проводки должна иметь только 2 знака после запятой, то при округлении и возникают злополучные копейки. Теория о том, что если где-то зависла копейка, то пройдя по графу найдем минус копейку - закроем одно на другое и все будет ок, к сожалению не проходит, проверено на распределениях затрат реальных предприятий.
В алгоритме, который я создал, численные методы не используются. Действует простая схема получил затраты - отдал, и так далее пока больше нечего получать. Применение данной схемы позволяет контролировать процесс, поэтому никаких отклонений быть не может.
6. Денис Маршалкин (Demarsh) 21.07.09 13:33
(1) Бухгалтерский смысл (хозяйственное содержание) решения системы - это и есть поиск тарифов, для единицы калькуляции каждого объекта. Т.е. после решения системы мы узнаем фактическую стоимость "чел/часов", "тн/км", "квт/час", "гкал" и т.п.
7. Игорь Исхаков (Ish_2) 21.07.09 13:48
(4) Дело в том , что я как-то столкнулся с решением СЛАУ в 1с и пробовал устойчивую и очень простую разновидность метода сопряженных градиентов для произовльной матрицы А(m,n) с нахождением обобщенного решения (нормального псевдорешения).
Если будет желание , как-нибудь обсудим.
8. Александр Рытов (Арчибальд) 21.07.09 14:25
(5) Поиск копейки по графу, действительно, крайне неблагодарное занятие. Не следует бескомпромиссно оставаться в математических рамках - см. 4 коммент.
Однако же остается вопрос расчета пресловутых коэффициентов. Или это за рамками статьи? Я понимаю, конечно, что главным в статье является "сквозное" прослеживание затрат от первичных до подажи - и это ценоо и полезно.
9. Александр Рытов (Арчибальд) 21.07.09 14:27
(7) Шо, невыпуклая задача была?
10. Денис Маршалкин (Demarsh) 21.07.09 15:44
(8) На самом деле я готов дать ответ или даже написать еще одну статью по поводу коэффициентов, но походу зашорен в своих формулировках и никак не могу понять вопрос.
В принципе, ни статья, ни обработка не предполагают расчета коэффициентов, т.е. в данном случае коэффициенты являются входящими параметрами - откуда они берутся и как рассчитываются остается за кадром. Для работы описанного алгоритма это не важно.
Вкратце, могу выделить следующие схемы для определения коэффициентов:
1. Коэффициенты могут браться из производственных отчетов соответствующих объектов учета, т.е. коэффициенты являются некими натуральными показателями. Например, АТЦ (маш/час), РМЦ (час), Электроснабжение (квт/ч), Котельная (гкал) и т.п. Собственно здесь расчет коэффициентов не происходит, происходит их сбор, на основе первичных документов.
2. Если объект производит некую продукцию (полуфабрикаты). То в качестве коэффициентов может использоваться Количество выпущенной продукции (полуфабрикатов)*Плановую стоимость для каждого наименования продукции. Что в данном случае считать под "Плановой стоимостью" - это вопрос скорее к ПЭО. В зависимости от вида производства данное понятие может принимать разные значения от нормативов до рыночной стоимости.
3. Коэффициенты для движения готовой продукции (полуфабрикатов) берутся такие же как и в п.2, если ведется партионный учет. При учете по средней необходимо также учесть начальные остатки.
4. Коэффициенты определяются пропорционально каким-либо первичным затратам или их совокупности. В основном применяются для общепроизводственных и общецеховых затрат. Здесь, по-моему, тоже никаких проблем - анализируем соответствующие проводки до начала распределения.
5. При использовании директ-костинга, коэффициенты могут рассчитываться пропорционально выручке, выручке (нетто), количеству реализованных товаров (продукции). Тут собственно предварительно анализируем реализацию.
6. Коэффициенты для распределения транспортно-заготовительных расходов - рассчитываются на основании движений тех или иных МТР (материально-технических ресурсов) по сумме или количеству. Соответственно анализируем движения по нужным счетам учета МТР.

Вот, на мой взгляд, основные схемы для получения коэффициентов распределения. Остальные, скорее всего, будут являться производными от вышеперечисленных.
11. Денис Маршалкин (Demarsh) 21.07.09 15:46
(8) Да, что касается тематики данной статьи, то здесь коэффициенты определяются одинаково, как суммы соответствующих движений в бухгалтерском учете.
12. Александр Рытов (Арчибальд) 21.07.09 15:50
(10, 11) Понятно. За пределами темы статьи.
13. Игорь Исхаков (Ish_2) 21.07.09 20:59
(9) Ага.
Но А*А=А*b ,где А*-транспонированная, и задача становится выпуклой.
Нужен был простой и всегда сходящийся, тупой алгоритм.
Чтоб никаких сложных операций , кроме умножения матрицы на вектор и скалярного произведения ,не было.
Для 1с достаточно.
14. Игорь Исхаков (Ish_2) 21.07.09 21:17
15. Grey (Grey) 21.08.09 02:12
Похоже от бухгалтерии ушли в численные мат. методы
16. Ададуров Виталий (adva) 06.03.14 15:27
Спасибо за публикацию, как раз понадобилось решить задачу, в ней описанную, а нет ли еще публикаций на данную тему, что-то кроме этой ничего не выдало?
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа