Как устроен изнутри расчет себестоимости в типовых конфигурациях

Меня зовут Валерий Дыков, я сотрудник компании «Аксиома». Расскажу, как устроен расчет себестоимости в типовых конфигурациях.

Сначала немного о себе. Я начал заниматься 1С давно, еще в 2000 году. 5 лет работал в фирме «1С» – делал УПП, как раз расчет себестоимости. Затем 12 лет занимался организацией разработки во франче. И в 2023 году в связи с массовым переходом с SAP на 1С снова вернулся к расчету себестоимости – занимаюсь расчетом себестоимости для тех, кто переходит с SAP на 1С.

Почему расчет себестоимости – интересная и актуальная тема, которую хочется обсудить?

• С одной стороны, механизм считается сложным – в конфигурациях много строк кода, связанных с расчетом себестоимости.

• А с другой стороны, есть много вопросов, особенно у новых пользователей 1С, которые с расчетом себестоимости в 1С не сталкивались, а привыкли его вести в другой системе.

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

• Расчет себестоимости – это просто. Как правило, дорабатывать его не надо.

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

Для кого этот доклад?

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

• Для разработчиков. Немного расскажу про матмодель, которая лежит в основе расчета себестоимости, где находится код, и как лучше его дорабатывать.

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

В большинстве типовых 1С-ных конфигурациях расчет себестоимости тесно связан с реглучетом, и это отличает 1С-ные конфигурации от не 1С-ных, потому что в SAP блок контроллинга – это вообще отдельная программа, в терминах SAP не сильно связанная с реглучетом.

Как правило, вся логика и код, связанные с расчетом себестоимости, находятся в каком-то одном документе: в УПП и ERP это документ «Расчет себестоимости», в БП – регламентная операция «Закрытие 20, 23, 25, 26 счетов».

Обычно расчет себестоимости везде состоит из одинаковых элементов:

• это некий регистр учета затрат – он может быть один или несколько;

• по этому регистру или регистрам формируют движения первичные документы;

• а сам расчет состоит из двух больших блоков:

  • распределение затрат;

  • корректировка стоимости списания.

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

• Анализ – корреспонденция откуда и куда пошли затраты.

• Ведомость – обороты и остатки.

И есть некоторый другой набор отчетов.

Эволюция расчета себестоимости

Теперь немного про историю.

Отправимся в 2004-2006 год. УПП 1.1, УТ 10.x, БП 1.6 и БП 2 – то, с чего в «восьмерке» начинался расчет себестоимости.

Основными способами оценки стоимости запасов в тех старых конфигурациях были:

• «Среднескользящая»;

• ФИФО;

• и ЛИФО.

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

В этих конфигурациях был еще один способ – «Средневзвешенная» оценка стоимости запасов, но она достигалась отдельным регламентным документом «Корректировка стоимости списания», который использовал граф затрат и корректировал среднескользящую до средневзвешенной оценки. Этот механизм с корректировкой стоимости через последовательный обход графа затрат до сих пор, спустя 20 лет, используется в БП 3.

По распределению затрат.

В старых конфигурациях давным-давно использовался следующий метод.

• Был некий регистр сведений с настройками распределения затрат.

• Были способы распределения.

• Был целый набор отдельных регистров для учета различных затрат.

• И распределение затрат выполнялось последовательно – мы распределяем затраты по каждому переделу и при этом считаем сумму после распределения затрат на каждый следующий передел.

Фактически расчет себестоимости выглядел как «попрыгунчик» – затраты последовательно перекладывались из одного регистра в другой или меняли измерения внутри одного регистра:

• из «Партий товаров» попадали в «Прямые затраты»;

• из «Прямых затрат» – в «Затраты на выпуск»;

• затем опять выпускались на склад и попадали в «Партии товаров» и так далее.

Затем вышла УПП 1.3, и в ней все изменилось. Основной смысл изменений в УПП 1.3 был в том, чтобы ускорить расчет себестоимости и уменьшить количество ошибок, проблем при этом расчете. Потому что в УПП 1.2 из-за использования старых механизмов, которые я описал, восстановление последовательности при расчете себестоимости занимало очень много времени, и надо было с этим что-то делать.

Какие были основные изменения?

• Способ оценки «Средневзвешенный» стали использовать как основной рекомендуемый способ. И до сих пор в типовых конфигурациях это основной рекомендуемый способ оценки. Этот способ хорош тем, что позволяет не восстанавливать последовательность – чтобы выполнить списание по средневзвешенной оценке, не надо перепроводить все документы строго последовательно и считать остаток на конец каждого документа.

• Более того, в УПП 1.3 было такое радикальное решение, от которого потом отказались в других конфигурациях – ФИФО было сделано тоже без перепроведения документов. Считался количественный остаток на конец периода и от него движения отсчитывались назад, чтобы определить, что именно должно было списаться по ФИФО в момент проведения документа. Сейчас такой радикальный подход уже не используется.

• Корректировка стоимости запасов через систему линейных уравнений. Этот механизм до сих пор жив в ERP, но его не стали добавлять в БП 3 – там вместо этого оптимизировали корректировку стоимости по графу, т.е. в БП 3 используется оптимизированный способ списания по графу.

• Также использование системы линейных уравнений позволило отказаться от использования кучи регистров – в УПП 1.3 для учета затрат был единый регистр, где учитывались затраты и на складе, и в производстве, и все другие/прочие затраты.

Следующее радикальное изменение – это распределение затрат в производстве.

Вы помните, что раньше распределение затрат настраивалось в регистре, а суммы считались при распределении на каждый следующий передел. А в УПП 1.3 принцип распределения затрат в производстве поменялся:

• Появилось закрытие месяца как процесс.

• Для правил распределения затрат стал использоваться общий концептуальный подход – задавался источник, база и получатель.

• Базы можно было задавать в режиме 1С:Предприятия в виде СКД: пользователь мог наделать сколько хочешь баз, и сколько хочешь способов распределения, удобных ему.

• И в процессе распределения суммы по каждому переделу не считались – проставлялись просто коэффициенты в граф, а расчет сумм потом выполнялся однократно для всего графа в рамках корректировки стоимости списания.

Условно в УПП 1.3 перешли от «попрыгунчиков» к единому регистру «Учет затрат», в котором все велось.

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

Какие выводы можно сделать из этой истории развития?

• За 18 лет механизмы расчета себестоимости не сильно поменялись.

  • В ERP осталась корректировка стоимости списания через СЛАУ.

  • А в БП 3 остался еще более древний механизм корректировки стоимости списания на графе.

• Во всех современных конфигурациях, начиная с УПП 1.3, наблюдается тенденция отказа от добавления своих “программных” баз распределения (считается, что слишком сложно для пользователей).

  • В УПП 1.3 можно было легко добавить базу в виде СКД, т.к. там использовался толстый клиент обычного приложения. А с выходом тонкого клиента от добавления баз в режиме 1С:Предприятия постепенно отказались.

  • В ERP сейчас вообще в режиме 1С:Предприятия свои базы не подобавляешь – даже в конфигураторе это сделать сложно.

  • А в БП 3 есть программный интерфейс, про который я дальше расскажу, где через код в переопределяемом модуле можно добавлять свои способы распределения.

• Все современные конфигурации делают основной акцент на средневзвешенную оценку, что позволяет не проводить по партиям, даже в БП 3.

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

Основные механизмы, которые используются при расчете себестоимости

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

• Про регистр с ключами.

• Про граф затрат.

• Про алгоритмы расчета себестоимости на графе.

• Про доработки.

Регистр учета затрат с ключами в измерениях

Первым делом рассмотрим регистр, где в качестве измерений используются ключи аналитики – это «Учет затрат» в УПП 1.3 и «Себестоимость товаров» в ERP.

Расскажу, как такой регистр устроен, и почему.

Первый вопрос: по какому принципу эти ключи создавались? Когда мы добавляли этот механизм с ключами в УПП, основной принцип был – чтобы работало быстро. Мы выбирали ключи по принципу, чтобы сочетаний аналитик в ключе было как можно меньше – чтобы в более-менее нормальной базе ключей данного вида получалось как можно меньше. Поэтому выбрали для ключей аналитики четыре справочника именно с такой структурой. Современные конфигурации, в принципе, этому правилу тоже следуют, но у ключей еще появился прикладной смысл.

Как организован быстрый поиск ключей? Казалось бы, «Ключи аналитики» – это справочник с реквизитами. Но так как этот справочник – технический, и новые ключи добавляются фактически в процессе проведения документов, нужно сделать так, чтобы существующие ключи быстро искались по полному набору измерений. Если ключ нашли – используем существующий, если нет – добавляем новый.

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

А в отчете, где нужна конкретная аналитика ключа, выводим реквизит из справочника ключей через точку – такой способ используется, например, в ERP.

Справочник ключей аналитики – технический или методический? В конфигурациях 1С он технический, т.к. пользователь не работает со справочником ключей аналитики напрямую. А вот в SAP, например, есть аналогичная сущность по смыслу, называется СПП-элемент – он методический. Там пользователи сами манипулируют этими ключами, которые в дальнейшем используются в контроллинге. Возможно, и в 1С он когда-нибудь тоже станет методическим.

Граф затрат

Теперь про граф затрат.

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

• Вершины — это комбинация аналитик, в которых нам нужно посчитать себестоимость.

• Ребра — это потоки затрат между вершинами. При этом к каждому ребру есть:

  • какой-то коэффициент передачи затрат;

  • и сумма, которая передается из одной вершины в другую.

Для расчета себестоимости в каждой вершине используются два простых принципа:

• Сумма всех входящих затрат, включая начальный остаток, равна сумме исходящих затрат из вершины, включая конечный остаток.

• Цена списания по направлениям (стоимость, деленная на коэффициент) из каждой вершины – одинаковая по всем направлениям.

На основании этих правил выполняется расчет себестоимости.

При этом в типовых конфигурациях, как я сказал, используются два метода расчета себестоимости: с графом и со СЛАУ.

Вот так выглядит условный граф затрат. Здесь каждая вершина графа — это комбинация аналитик, в данном случае, «Счет учета», «Статья затрат», «Номенклатурная группа», «Продукция».

На этапе распределения мы проставляем коэффициенты – в данном случае, объем выпуска k. Например, мы знаем, что:

• песка мы добыли 400 тонн: k=400;

• а щебня мы добыли 600 тонн: k= 600.

Следующий этап – корректировка стоимости.

• Мы знаем, что у вершины с номенклатурной группой ОПИ на входе было 100 рублей. Это значит, что на выходе у нее тоже должно быть 100 рублей, и цена списания по каждому направлению должна быть одинаковая.

• Делим 100 рублей по полученным на предыдущем этапе коэффициентам и получаем сумму списания по каждому направлению.

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

«Метод бегущей волны»

Фактически я сейчас рассказал принцип «метода бегущей волны» – расчет себестоимости на графе, который используется в БП 3.

По проводкам первичных документов составляется граф затрат:

• Для ребер счетов с количественным учетом в качестве коэффициентов используется количество. А для счетов, где количественного учета нет – суммы.

• По результатам распределения затрат в вершины добавляются недостающие дуги с коэффициентами из базы распределения.

• Дальше граф упорядочивается:

  • слева ставятся вершины, в которых нет входов, но есть выходы;

  • а справа – те, где есть только входы, но выходов, наоборот, нет.

• Граф проходится последовательно, и для каждой вершины рассчитывается стоимость списания.

• Если встречаются циклы («встречный выпуск» в терминах УПП), мы их разрываем и в случае БП просчитываем граф два раза, чтобы посчитать встречный выпуск более точно. Никаких отдельных настроек со встречным выпуском в БП нет, поэтому точность при встречном выпуске получается приблизительная.

СЛАУ

Теперь про СЛАУ. Здесь тоже все просто.

На входе – такой же граф затрат, но в данном случае для каждой вершины графа составляется уравнение:

• сумма входящих затрат – неизвестная X (цена списания из вершины) умножить на коэффициент;

• минус сумма исходящих затрат;

• равно начальный остаток минус конечный остаток и списание по фиксированной стоимости.

В итоге у нас получается система уравнений, где столько уравнений сколько вершин.

Решаем эту систему линейных уравнений и получаем цену списания из каждой вершины.

В ERP сейчас используется платформенный метод решения систем линейных уравнений.

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

Такой приближённый метод приводил к тому, что зависали копейки – мы считаем приближённо, значит, могут зависнуть копейки.

Для копеек был отдельный простейший алгоритм – мы искали все вершины, где есть копейки, но нет количества, и распределяли их по направлению с наибольшей суммой, в конце которого какое-то количество остаётся.

Задача “куда деть ошибки округления” стандартная, при применении любого приближенного метода решения СЛАУ.

Фичи при расчете себестоимости

Какие фичи получаются при использовании такого подхода с системой линейных уравнений?

Первое больше не фича, а вопрос, который возникает: «Как нам сделать, когда нам нужно сделать списание по фиксированной стоимости так, чтобы расчет себестоимости его не трогал?»

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

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

Основная причина в том, что достаточным условием сходимости нашей системы уравнений, которую мы рассчитываем методом простых итераций, являются неотрицательные остатки в вершинах по количеству. Если у нас есть отрицательные остатки, то может сойтись, а может не сойтись. И кто помнит гигантские суммы при расчёте в УПП – это как раз результат того, что в каких-то вершинах были отрицательные остатки и полученная система не сходилась методом простых итераций.

Ещё часто задаваемый вопрос: «Можно ли в 100 раз ускорить расчёт себестоимости, который основан на графе?»

Да, можно, если уменьшить граф. Вообще использование графа для расчёта себестоимости – это широко известная тема. Гуглим в интернете «граф затрат», там есть множество рекомендаций, как можно сократить размер графа при расчёте себестоимости, так, чтобы там стало меньше вершин, и можно было всё быстрее посчитать.

Для манипулирования графом и СЛАУ в памяти есть определенные технические особенности – их можно посмотреть на слайде.

Какие основные доработки просят пользователи?

Какие основные доработки просят пользователи?

• Отражение в затратах новых документов.

• Новая аналитика учета затрат

• Новый способ или база распределения.

• Какое-нибудь хитрое закрытие периода.

Расскажу, как это сделать в разных типовых конфигурацияхю

Для отражения в учете затрат новых документов и операций:

• В УПП у регистра «УчетЗатрат» есть табличный макет «ПараметрыФормированияДвижений». Для нового документа добавляем в эту табличку новую строку, где описываем, как будут формироваться движения.

• Так как БП при расчёте себестоимости у нас опирается на регистр «Хозрасчётный», мы можем своими документами свободно делать проводки по регистру «Хозрасчётный» – то, что получится, будет учтено расчётом себестоимости.

• В ERP чуть сложнее – там регистров много, и они более сложные. Поэтому для ERP самый действенный метод – не делать движения в своих документах напрямую, а программно генерировать из них типовые документы, которые уже делают правильные движения по всем затратным регистрам и ничего не ломают при этом.

Следующая задача – добавить новую аналитику учёта затрат.

• В УПП – добавляем колонку в один из ключевых регистров и описываем логику ее заполнения в макете «ПараметрыФормированияДвижений».

• В БП это тоже сделать достаточно просто:

  • Можно менять аналитику на существующих счетах – например, на 20-м счёте можно вместо «Продукции» указать какую-нибудь другую аналитику, она тоже учтётся в расчёте себестоимости.

  • Можно добавлять свои субсчета, например, 20.03, 20.04, 20.05 со своей аналитикой. Но тут надо быть осторожным. Если субконто «Продукция» можно заменить на свое достаточно безопасно и практически ничего в типовой менять не придётся, то номенклатурную группу или статью сменить сложнее – потребуются изменения в типовой.

• В ERP ещё чуть сложнее. Самый простой способ добавить аналитику затрат в ERP – это добавить реквизиты в какие-нибудь существующие справочники, которые являются аналитикой затрат.

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

• В БП есть специальный переопределяемый общий модуль ПравилаРаспределенияРасходовМодификацияКонфигурации – на Инфостарте есть статья с примером использования этого общего модуля. Переопределяя процедуры в этом общем модуле, вы можете добавлять свои произвольные правила распределения затрат либо отключать типовые правила.

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

Теперь о том, как реализовать прозрачный/ролевой/сложный процесс закрытия месяца:

• В УПП появился целый бизнес-процесс «Закрытие месяца», где разные пользователи могли выполнять разные операции. В современных конфигурациях такого нет.

• Но в БП регламентные операции можно выполнять отдельно, без использования обработки. Поэтому, если вы, например, используете УХ, то можно использовать механизм согласования документов с бизнес-процессом и привязывать к его шагам регламентные операции, и будет работать.

• В ERP придется дорабатывать обработку закрытия периода.

Какие ошибки допускаются при доработке расчета себестоимости

Какие наиболее частые ошибки при доработке расчета себестоимости:

1. Первая главная ошибка – внесение изменений в типовые механизмы расчета себестоимости, которые для этого не предназначены. Лучше так не делать – лучше использовать механизмы расчета себестоимости как черный ящик.

2. Добавление излишней аналитики. Как правило, после того как вы посчитали себестоимость в производстве, на выходе у вас все равно получится продукция, лежащая на складе. От того, что вы детально распределите затраты где-то в середине, на выходе все равно все попадет в котел, усреднится и это будет стоимость продукции. Поэтому всегда, когда вы хотите что-то детально распределить, подумайте, как и зачем эта информация будет использоваться.

3. Распределение все на все. Когда мы пытаемся детально распределить много-много входящих затрат на много-много выпускаемой продукции, то количество распределений – это получается фактически перемножение количества входов на количество выходов. Распределений получается очень много, все работает очень медленно. Чтобы этого избежать, сворачивайте затраты внутри производства – распределяйте весь вход на какую-то одну аналитику в середине, а затем одну аналитику из середины на выход. Таким образом количество распределений будет не произведением, а суммой – комбинацией аналитик на входе и выходе.

4. Следующая ошибка происходит, когда мы пытаемся механизм учета затрат использовать не по назначению: протаскиваем через него партии для целей НДС, ГОЗ или складского учета. Это все загромождает.

5. Лишние переделы тоже замедляют расчет себестоимости.

Как устроен расчет себестоимости в разных конфигурациях

В ERP (УТ 11)

Теперь немного технических деталей по расчету себестоимости в ERP.

Цитата бывшего сотрудника фирмы «1С», который отвечал за разработку ERP: «В ERP первична методология, а тех. решение и сам код – вторичны».

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

Чтобы изучить, как это работает, гуглим в интернете «Андрей Лабынин». Это ведущий разработчик расчета себестоимости в ERP – он работал над ним еще и для УПП и даже раньше УПП. У него есть куча выступлений, где он рассказывает о том, как все посчитать в ERP типовыми средствами.

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

Если хочется посмотреть код, его можно посмотреть:

• точка входа – в общем РасчетСебестоимости (РасчетСебестоимостиЛокализация).

• Решение СЛАУ – в методе РасчетСебестоимостиРешениеСЛУ.РешитьСЛУПлатформой_СебестоимостьПредприятия()

• Логика распределение расходов – в общих модулях РасчетСебестоимостиМатериальныеЗатраты, РасчетСебестоимостиПостатейныеЗатраты, ДоходыИРасходыСервер

В БП3

Про БП попробую рассказать чуть больше.

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

Как работает в целом расчет себестоимости БП3?

• Все настройки для расчета себестоимости собираются в служебный справочник «Настройки учета затрат», который можно подправить в режиме 1С:Предприятие и скорректировать так, как вам надо.

• Затем запускается регламентная операция «Закрытие счетов 20, 23, 25, 26», которая распределяет затраты по правилам и выполняет корректировку стоимости списания.

• Все операции выполняются во временных таблицах, в отладчике это легко просматривается.

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

• Составляется общая таблица правил распределения в виде:

  • входа – источника, откуда затраты отбирать;

  • выхода – куда распределять;

  • и по какой базе.

• В эту таблицу добавляются:

  • типовые правила, их там штук 25;

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

• Дальше составляется таблица со всеми комбинациями разрезов аналитик, где есть остатки затрат на момент расчета себестоимости.

• К таблице с набором аналитик последовательно применяются правила распределения. Если по какой-то комбинации затрат применилось определенное правило, эта комбинация помечается как использованная, и следующие правила к ней применяться не будут.

• Комбинации аналитик, которые получаются в результате выполнения правил, также добавляются в эту табличку.

• Табличка обходится два раза – в результате распределяются все затраты, которые мы смогли распределить по правилам.

Какой для нас полезный вывод из этого:

• Последовательность правил важна, поэтому если вы будете добавлять свои правила, их лучше добавлять перед типовыми, иначе типовые все распределят, а вашим правилам ничего не останется.

• В переопределяемом общем модуле ПравилаРаспределенияРасходовМодификацияКонфигурации написано много комментариев – там все эти детали можно прочитать.

Отлаживать в БП3 расчет себестоимости тоже просто. Если мы запускаем 1С с параметром «РежимеОтладки», у нас в журнал регистрации будет выведен граф затрат. И дальше можно его визуализировать – например, на сайте http://www.webgraphviz.com/.

Весь расчет себестоимости ведется в говорящих временных табличках – в отладчике их все можно посмотреть, и посмотреть, что пошло не так.

Итого для разработчиков

В принципе, расчет себестоимости – это просто.

• Он использует простейшие алгоритмы, для понимания которых достаточно первого семестра первого курса института, когда решается система линейных уравнений.

• В целом расчет себестоимости везде одинаковый – он хорошо структурирован и от предметной области не зависит. Из этих шагов он состоит в любой конфигурации на протяжении 18 лет, строится примерно одинаково.

• Изменения в модулях, связанных с механикой расчета себестоимости, достаточно редкие.

• Базовые механизмы уже 18 лет не меняются.

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

Если на проекте нужно доработать расчет себестоимости – скорее всего, что-то пошло не так, и надо разбираться, почему вас это просят.

И цитата действующего уже сотрудника 1С: «Трех субконто хватит всем». И действительно, четырех аналитик в БП (подразделение + 3 субконто) для большинства задач в затратах хватает.

Вопросы и ответы

Насколько сложно сейчас в типовом механизме расчета себестоимости добавить собственную аналитику затрат?

Смотря в какой конфигурации.

В БП добавить легко – просто заменяем существующее субконто на другое. Например, если мы хотим на 20-м счете не с точностью до продукции затраты собирать, а с точностью до какого-то заказа, заменяем аналитику «Продукция» на 20-м счете на свой справочник. Либо добавляем в 20-й счет свой субсчет с аналитикой «Заказ» вместо «Продукции». Вот мы и добавили новую аналитику.

Если нужно больше аналитик, можем использовать подход с ключевыми справочниками (доп. аналитика) – добавляем в субконто ключевой справочник, где в реквизите находится нужная аналитика. Правда тогда придется немного доработать расчет себестоимости, чтобы он подтягивал аналитику через точку. Но это тоже сделать несложно.

В ERP сложнее.

В БП и в ERP при одинаковых вводных документах себестоимость будет одинаковой или разная?

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

*************

Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART EVENT.