В 1С существует несколько комплектов настроек, которые определяют правила учета в программе Настройки параметров учета - самый первый.

Довольно часто попадают в поле зрения базы 1С УПП и Комплексной автоматизации, настройки в которых не были продуманы при внедрении и по мере накопления документов накопились и серьезные проблемы. Как правило, это неудачный результат экономии на внедрении. Представленные здесь материалы не заменяют работу специалистов. Их задача скорее - дать пищу для размышлений и сделать Ваше общение со специалистом 1С более предметным и ответственным.

Я не планирую здесь перепечатывать справку 1С. Добравшись до Настроек параметров учета не поленитесь нажать на вопросик в правом нижнем углу формы. Базовые моменты настроек там описаны достаточно понятно.

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

1. Где найти Настройки параметров учета

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

Необходимо перейти в интерфейс Заведующий учетом. В этом интерфейсе находим меню Настройка учета - Настройка параметров учета:

Открывается окно настроек, где в первую очередь нас будет интересовать подводный камень №1:

2. Режим учета затрат

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

А чуть ниже мы видим детальные настройки партионного учета.

И здесь возникает сразу 2 вопроса:

1. А точно Расширенная аналитика (иначе ее еще называют РАУЗ)? Может быть лучше выбрать традиционный партионный учет.

2. Что означает Регламентированный учет с дополнительной аналитикой - это и есть РАУЗ или речь о какой-то еще настройке?

Начнем с первого вопроса:

3. Расширенный учет затрат или партионный

Какого кота тащить из мешка?

Расширенная аналитика - в первую очередь важна для производств, так как:

+ Быстрее рассчитывает себестоимость. Правда это всерьез заметно на очень больших объемах.

В Комплексной автоматизации 1.1 учет производства возможен только в Расширенной аналитике. В режиме партионного учета просто не проводится документ Расчет себестоимости.

И преимущество для всех: можно не думать о порядке ввода документов в пределах месяца, так как в пределах месяца даже ФИФО считается по средней. Пересчет по ФИФО делается при закрытии месяца.

Есть и сложности:

× Не умеет резервировать конкретные серии под заказы покупателей. Дело в том, что при резервировании по сериям заказ пишется прямо в регистры партионного учета и резервирует конкретные партии. Но в регистры Расширенной аналитики нельзя записать заказ. Там не предусмотрено такой аналитики партий.

× Учет МПЗ по ФИФО поддерживается не до партии, а до дня поступления и поставщика. Опять же причина проста - в аналитике партий нет документа партии.

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

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

Такое требование нередко в торговых компаниях. Но для его выполнения необходим высокий уровень организации процесса.

Как минимум нужно, чтобы:

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

Я несколько раз сталкивалась с более или менее успешными реализациями такой концепции учета на 1С УПП. Работает, но только когда действительно сильно нужно.

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

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

Отчеты по движению ТМЦ и затрат

Режимы учета затрат принципиально различаются в плане отчетов по себестоимости МПЗ и учету затрат в производстве. в 1С УПП и КА 1.1 для этого предусмотрено два отдельных комплекта отчетов. Один для классического партионного учета, другой - для расширенной аналитики.

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

Вывод

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

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

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

то тут следует рассмотреть переход на партионный учет.

Итак, в настройках мы оставили РАУЗ. Но, все - таки... смущает фраза Регламентированный учет с дополнительной аналитикой. То есть, мы подошли ко второму вопросу:

4. Режим использования расширенной аналитики

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

1. Выберем режим учета затрат Партионный учет. В открывшемся окне снимем флаг Использовать расширенную аналитику затрат:

Предупреждение нас не пугает, база-то пока пустая.

2. Нажимаем на Изменить настройку и снова видим предупреждение о необходимости перепровести все документы:

3. Соглашаемся и с удивлением смотрим на следующее окно:

Вот они - варианты настройки Расширенной аналитики. И содержат эти варианты очень существенные различия.

Читаем пояснения под каждым вариантом внимательно. Вот важный момент. Только последний вариант позволяет нам вводить данные управленческого учета независимо от регламентированного. Технически это выражается в том, что мы имеем два отдельных регистра Учет затрат: регламентированный и управленческий.

Плюс изюминка - возможность вести учет затрат по проектам и управленческим подразделениям тоже предполагается только для последнего варианта:

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

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

5. Достигаем, наконец, результата: изменение варианта детализации Расширенной аналитики затрат:

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

4. Использовать партионный учет

Рассмотрим особенности настроек партионного учета:

1. Списание партий документом.

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

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

2. Списывать партии расходным ордером.

Эта настройка не управляет самим фактом использования ордерной схемы на складах. Такая возможность в 1С УПП и Комплексной автоматизации 1.1 есть всегда, вне зависимости от настроек параметров учета.

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

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

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

Предупрежу вас, что при этой схеме возникают неожиданные следствия в бухгалтерском учете. В бухгалтерских отчетах: ОСВ, карточках счета документом в проводке выступают документы Расходный ордер на товары, а не Реализация товаров и услуг. Бухгалтера, конечно, по началу нервничают. Неудобно.

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

3. Детализация учета.

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

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

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

Но если себестоимость товара вам важно оценивать отдельно для каждой организации, то необходимо указать здесь организации. Иначе управленческий учет себестоимости партий будет "ползти":

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

Учитесь новому каждый день и меняйте свою жизнь к лучшему!

Записи вебинаров

1С РАУЗ - технология или методология? - статья редактируется

Проанализировав доступные мне источники по теме РАУЗ (на июль 2014 года, предыдущая версия статьи была написана в 2011 году), обнаружил, что информация об особенностях методологии учета затрат с помощью подсистемы РАУЗ по-прежнему довольно скудная. Как правило, все опять сводится к констатации нескольких очевидных фактов:

• РАУЗ использует системы линейных алгебраических уравнений (СЛАУ)
• РАУЗ помогает оптимизировать структуру метаданных – уменьшить число регистров
• РАУЗ обеспечивает «совмещенный» учет МПЗ и затрат
• РАУЗ обеспечивает «огромный» объем аналитических данных
• и вообще, РАУЗ – может все (?!), это очень прогрессивно и очень хорошо для пользователей - просто некоторые пользователи еще этого не понимают

Если и появляются какие-либо публикации по данной теме, то в первую очередь они касаются технологических аспектов реализации РАУЗ - настройки параметров системы, особенностей проведения отдельных документов, движений по регистрам и т.п. Причем, обсуждая эти технологические аспекты, многие специалисты пребывают в полной уверенности, что обсуждают именно методологические вопросы учета затрат. П убликации, в которых затрагиваются вопросы составления и решения СЛАУ, носят достаточно общий характер, т.к. не раскрывают конкретных особенностей использования СЛАУ в подсистеме РАУЗ - не обсуждаются достоинства и недостатки выбранного разработчиками варианта составления уравнений баланса затрат. Что же касается практического применения положений теории Графов затрат , де-факто (и возможно - не до конца осознанно) заложенной разработчиками в подсистему РАУЗ, то как и прежде эти вопросы не находят своего отражения в публикациях . Сейчас уже можно констатировать, что процесс разработки данной подсистемы был основан скорее на отдельных практических наработках авторов, чем на глубоком понимании теории Графов затрат. Об этом свидетельствуют имеющиеся в РАУЗ методологические «ляпы» принципиального характера.

Попробуем еще раз (очень тезисно) разобраться с тем, какая методологическая база заложена в основу работы подсистемы РАУЗ. В данной статье об этом действительно можно говорить кратко, т.к. все подробности работы модели предметной области, которая называется Графом затрат, можно посмотреть на сайте , посвященном изучению теории и практики расчета себестоимости с помощью Графов затрат . Перед чтением настоящей статьи желательно обеспечить правильную «настройку» мышления, для чего в соответствующем разделе сайта можно ознакомиться с основами методологии автоматизированной формы учета на основе объектно-ориентированного подхода (АФУ ООП ). Для читателей, у которых нет времени или желания заниматься предварительной подготовкой к чтению статьи (почему-то автор уверен, что такие читатели найдутся), кратко рассмотрим в начале статьи некоторые основные тезисы АФУ ООП.

Содержание статьи:

Объектный подход к методологии учета ()

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

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

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

К сожалению, такой подход к профессиональной деятельности подобен инфекционному заболеванию, в результате которого подобным отношением к методологии бухгалтерского учета заражаются их ближайшие коллеги и соратники - IT-специалисты, что безусловно проявляется в создаваемых ими автоматизированных системах учета. По аналогии с широко известным термином «лоскутная» автоматизация в таких автоматизированных системах учета можно говорить о «лоскутной» методологии учета. В этом случае при создании каких-либо частей (подсистем) учетных систем используются некие отдельные идеи и наработки группы разработчиков, часто без глубокой теоретической проработки формальных моделей предметной области. Подобная ситуация наблюдается и с подсистемой РАУЗ, методологическим фундаментом которой должна была бы выступать теория графов затрат, однако на практике получилось несколько иначе. Но подсистема создана и нам необходимо хотя бы приблизительно понимать, как она работает и почему она работает именно таким образом.

Можно сказать, что в основе методологии АФУ ООП лежат теория графов и применение объектно-ориентированного подхода к области методологии учета – ко всем участкам учета, не только к учету затрат. Это означает, что вместо счетов бухгалтерского (налогового, управленческого) учета и их корреспонденций рассматриваются объекты учета и их отношения. Каждый объект учета характеризуется набором свойств, определяющих его место и возможное поведение в модели предприятия. При таком подходе можно говорить о том, что объекты учета, характеризующие активы и пассивы предприятия вступают между собой в отношения - обмениваются потоками стоимости , причем каждый поток стоимости также является объектом учета и имеет свои свойства, например, такие, как:

• объект учета – источник, в котором поток начинается
• объект учета – получатель, в котором поток заканчивается
• стоимость
• количество

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

Используя модель хозяйственной деятельности предприятия в виде графа можно сказать, что стоимость начисленной амортизации как-бы «перетекла» с кредита счета Амортизация по маршруту: Амортизация → Цех 1 → Цех 2 → Цех 3 → Продажа в дебет счета учета продаж, где формируется себестоимость проданной продукции.

Де-факто теория графов и объектный подход используются при создании всех современных автоматизированных систем учета, основанных на двойной записи. Причем, не имеет значения, какая компания является разработчиком автоматизированной системы - 1С, Галактика, SAP, Oracle и т.д., просто каждый разработчик своими средствами и в меру своего понимания ситуации пытается реализовать модель предметной области - Граф предприятия, узлами которого выступают объекты учета. Сейчас практически невозможно найти автоматизированную систему учета, которая бы позволяла пользователям работать только со счетами бухгалтерского учета без какой-либо дополнительной аналитики, т.е. методология АФУ ООП уже давно и прочно вошла в практику автоматизированного учета, хотя многим пользователям и разработчикам до сих пор удается не замечать этого очевидного факта.

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

В любой автоматизированной системе учета, использующей двойную запись для отражения информации о хозяйственных операциях, спрятана учетная модель предприятия в виде Графа предприятия . Это значит, что все хозяйственные операции предприятия за интересующий период можно представить в виде ориентированного графа, узлами которого являются объекты учета (активы и пассивы), а дугами - соединяющие их потоки стоимости. Причем, этот граф существует в таблицах автоматизированной системы учета независимо от того, знают ли о его существовании разработчики и пользователи системы или не знают. Если знают, то учитывают этот факт при разработке системы и при дальнейшей работе с ней, что помогает избежать многих методологических казусов. Если же не знают - то разработка системы часто идет «на авось», как получится, что неминуемо приводит к методологическим промахам, а также сильно утяжеляет и даже запутывает логику отражения хозяйственных операций в системе учета, а значит - затрудняет работу пользователей, снижает их производительность труда.

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

Участок (фрагмент, подграф) Графа предприятия, отвечающий за себестоимость продукции (работ, услуг), называется Графом затрат. Потоки стоимости в Графе затрат называются потоками затрат , а объекты учета называются центрами затрат .

Объекты учета в подсистеме РАУЗ ()

Не является исключением (в смысле использования АФУ ООП) и такой программный продукт, как 1С УПП. В данной статье предполагается, что читатель имеет представление о том, что такое метаданные и как в конфигураторе можно посмотреть их структуру. Рассмотрим, д ля примера, структуру регистра накопления УчетЗатратРегл из подсистемы РАУЗ:

В регистре накопления УчетЗатратРегл :

• измерения определяют свойства объекта - ОбъектУчета 1 (ЦЗ 1)
  
• реквизиты определяют свойства объекта - ОбъектУчета 2 (ЦЗ 2)
• ресурсы характеризуют свойства объекта - поток стоимости, который в подсистеме РАУЗ будем называть ПотокЗатрат

т.е. данный регистр накопления предназначен для хранения информации о взаимодействии двух объектов учета - корреспондирующих между собой центров затрат, а точнее - для хранения информации о таком объекте учета, как поток затрат - который соединяет между собой пару центров затрат. Поскольку подсистема РАУЗ предназначена для учета затрат, будем дальше называть объекты учета - центрами затрат . Подробнее ознакомиться с теоретическими аспектами формирования топологии Графа затрат с помощью центров затрат и потоков затрат можно, например, в статьях:

• Центры затрат - узлы Графа затрат
• Потоки затрат - дуги Графа затрат
• Элементарный поток вторичных затрат

Напомним читателю, что граф - это не только нарисованные на листе бумаги или на экране компьютера различные геометрические фигурки, соединенные между собой линиями или стрелочками. Граф, как комбинаторный абстрактный объект, представляет собой более объемное понятие - его можно с одинаковым успехом представить, как в виде рисунка, так и в виде таблицы или перечня узлов и дуг. Это означает, что существуют различные формы представления одного и того же графа - геометрическая форма, матричная (табличная) форма и форма представления графа с помощью множеств. Все формы представления графов являются «равноправными», т.е. модель предприятия не меняется от того, что будет представлена не в виде таблицы (например, журнала хозяйственных операций), а в виде рисунка, на котором счета учета будут соединены стрелочками - всем известные бухгалтерские «самолетики».

Структура регистра накопления УчетЗатратРегл подразумевает, что каждая запись в нем характеризует взаимодействие между двумя соседними центрами затрат, а вся совокупность записей за рассматриваемый период позволяет получить информацию о системе взаимодействующих между собой центров затрат. Другими словами, регистр накопления УчетЗатратРегл представляет собой классический вариант таблицы, в которой содержится информация о Графе затрат, т.е. можно говорить о том, что работа подсистемы РАУЗ базируется на использовании модели предприятия в виде графа, представленного в табличной форме.

Формирование свойств центров затрат в подсистеме РАУЗ ()

Максимально возможный перечень всех возможных свойств центров затрат представлен в РАУЗ виде набора из четырех аналитик (и кораналитик), причем состав этих аналитик может меняться в разных релизах УПП (и в других продуктах 1С). Для целей настоящей статьи конкретный состав аналитик не имеет особого значения, т.к. нас сейчас интересует сам принцип выделения центров затрат в подсистеме РАУЗ - мы должны понять, каким образом в этой подсистеме происходит формирование модели предприятия в виде Графа затрат. Разделение перечня аналитик именно на четыре вида (группы) вызвано, очевидно, исключительно технологическими причинами, т.к. с точки зрения методологии учета затрат с помощью Графов затрат нет никаких особых причин разделять этот единый набор свойств центров затрат именно таким образом. Скорее всего, разработчики посчитали, что такое разделение аналитик должно оптимизировать количество ключей аналитики в соответствующих справочниках подсистемы РАУЗ, т.к. какие-то отдельные ключи аналитики могут использоваться во многих центрах затрат.

На рисунке представлен механизм формирования перечня свойств центра затрат ЦЗ 1 :

и механизм формирования перечня свойств корреспондирующего центра затрат ЦЗ2 :

По-существу, в подсистеме РАУЗ произведена попытка создания регистра накопления для отражения обмена потоками затрат между универсальными центрами затрат, т.е. центрами затрат с одинаковым набором свойств. На самом деле, центры затрат с подобным перечнем свойств в 1С УПП представить себе трудно, реальные центры затрат в данном регистре характеризуются с помощью только некоторых свойств из данного перечня - для разных центров затрат используются разные наборы свойств.

Еще раз обратим внимание читателя на тот факт, что подсистема РАУЗ работает с объектами учета, которые мы назвали центрами затрат(!). На обоих рисунках хорошо видно, что свойство СчетУчета является всего лишь одним из нескольких десятков свойств, характеризующих центры затрат в регистре накопления УчетЗатратРегл . Корреспондирующие центры затрат обмениваются между собой потоками затрат.

Регистр накопления УчетЗатратРегл устроен довольно просто - в нем учитываются потоки затрат между корреспондирующими центрами затрат. Каждая запись в регистре отражает операцию обмена потоками затрат между парой центров затрат:

• ЕСЛИ ВидДвижения=Расход, то ЦЗ 1 является источником затрат (кредитуемым центром затрат), а ЦЗ 2 – получателем затрат (дебетуемым центром затрат)
• ЕСЛИ ВидДвижения=Приход – то все наоборот

Перечень свойств объекта учета ПотокЗатрат определяется составом ресурсов регистра накопления УчетЗатратРегл :

• Количество
• КоличествоНУ
• Стоимость
• СтоимостьНУ
• ПостояннаяРазница

Здесь следует особо отметить, что в подсистеме РАУЗ свойство СтатьяЗатрат является свойством центра затрат , а не свойством потока затрат(!) . С точки зрения теории Графов затрат это означает, что в подсистеме РАУЗ 1С УПП статьи затрат не выполняют своей основной функции - увеличивать глубину аналитического учета на входах центров затрат, сокращая общее количество центров затрат в модели предприятия (см. Статьи затрат). Это касается также и других аналитик. Можно сказать, что центр затрат в подсистеме РАУЗ формируется с помощью логического «И » - центром затрат считается объект учета, который характеризуется - И подразделением И счетом БУ И счетом НУ И статьей затрат И ... т.д.

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

Довольно часто в адрес подсистемы РАУЗ от ее пользователей можно услышать критические замечания, связанные с тем, что процессы движения потоков затрат в регистре УчетЗатратРегл являются непрозрачными, что их невозможно контролировать. Безусловно, это является серьезным методологическим недостатком подсистемы РАУЗ, причину такого положения дел мы обсудили в предыдущем абзаце. Действительно, «охватить умом» сложные процессы движения потоков затрат в модели предприятия объемом в десятки или сотни тысяч центров затрат в реальном масштабе времени может далеко не каждый специалист по расчету себестоимости, даже имея инструментарий для визуализации потоков затрат (которого в РАУЗ нет). Визуализация потоков затрат могла бы помочь «перевести» информацию, содержащуюся в Графе затрат, с языка табличной формы представления на язык графической формы представления.

Кроме того, формируемые подсистемой РАУЗ центры затрат по большей части не имеют какого-либо ярко выраженного экономического назначения, их появление в регистре накопления УчетЗатратРегл обусловлено сугубо технологическими причинами, т.е. необходимостью произвести расчет себестоимости по алгоритмам РАУЗ. Это приводит к тому, что у пользователя практически отсутствует возможность осознанной работы с центрами затрат, как с ключевыми объектами модели предприятия.

Классификация центров затрат в подсистеме РАУЗ ()

Одним из основных принципов объектного подхода является принцип наследования, позволяющий описать свойства нового класса объектов на основе свойств уже существующего (родительского) класса объектов (см.Классификация центров затрат ). Поскольку в подсистеме РАУЗ, пусть и в примитивном виде, но предполагается использование объектного подхода к методологии учета затрат и МПЗ, рассмотрим подробнее - каким образом используется принцип наследования для центров затрат из регистра накопления УчетЗатратРегл .

Сначала попытаемся определить состав классов центров затрат, используемых в подсистеме РАУЗ. Для этого из общего набора аналитик выделим те аналитики, которые могут использоваться всеми (или подавляющим большинством) центрами затрат. Например, в качестве такого общего набора аналитик можно выделить:

• Раздел учета
• Организация
• СчетУчета
• СчетУчетаНУ

Будем считать, что этот набор из четырех аналитик (свойств) определяет родительский класс центров затрат из регистра накопления УчетЗатратРегл. Свойства родительского класса будем называть общими свойствами центров затрат, т.е. данный набор свойств присутствует у всех центров затрат в подсистеме РАУЗ. В качестве основы для дальнейшей классификации центров затрат можно, например, использовать значения аналитики Раздел учета. В этом случае перечень классов центров затрат подсистемы РАУЗ будет определяться перечислением РазделыУчета . Выделение классов (т.е. специализация центров затрат) производится добавлением к набору общих свойств центров затрат набора специальных свойств, присущих только выделенному классу центров затрат. В качестве примера на рисунке представлены два класса центров затрат - класс МПЗ и класс Затраты :

Как мы уже упоминали в первом разделе статьи, свойства объектов учета могут определять их поведенческие аспекты в модели предприятия. Например, поведение в Графе затрат центров затрат класса Затраты может характеризоваться свойством Затраты.СтатьяЗатрат , т.к. именно это свойство может использоваться для настроки способов распределения статей затрат, т.е. правил распределения потоков вторичных затрат с выходов центров затрат во время проведения документа Расчет себестоимости выпуска . Практикующие бухгалтеры часто утверждают, что во время закрытия затрат предприятия происходит распределение затрат каждой статьи затрат. В подсистеме РАУЗ это утверждение нельзя признать корректным, т.к. в конце периода распределяются не затраты каждой статьи затрат, а затраты каждого центра затрат, в котором свойство СтатьяЗатрат является только одним из характеризующих его свойств.

Поведение же центров затрат класса МПЗ определяется не свойствами самих центров затрат, а внешними алгоритмами подсистемы РАУЗ. Работа этих алгоритмов зависит от того, какой метод оценки стоимости МПЗ при выбытии выбран предприятием - по средней или ФИФО.

По мнению автора, разработчики подсистемы РАУЗ «погорячились», включив в подсистему РАУЗ данный класс центров затрат в таком виде, т.к. это приводит к некорректной работе метода ФИФО (см. ). Желательно было бы разделить класс МПЗ , как минимум, на два класса:

• МПЗ.Материалы
• МПЗ.ГотоваяПродукция

и только последний класс включить в подсистему РАУЗ.

А если говорить совсем откровенно, то и класс готовой продукции также нужно разделить еще на два класса:

• МПЗ.ГотоваяПродукцияПрошлыхПериодов
• МПЗ.ГотоваяПродукцияТекущегоПериода
  

Использовать в РАУЗ нужно только класс готовой продукции текущего периода.

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

Пример взаимодействия центров затрат в подсистеме РАУЗ ()

Рассмотрим на примере, каким образом появляются и взаимодействуют между собой центры затрат в подсистеме РАУЗ. Предположим, что работник Цеха №2 предприятия Одуванчик должен отремонтировать принадлежащий предприятию автомобиль, у которого вышел из строя инжектор. Для начала, предприятие Одуванчик должно приобрести инжектор. Данная хозяйственная операция была отражена в бухгалтерском учете с помощью документа Поступление товаров и услуг №1:

УчетЗатратРегл появились два центра затрат:

• ЦЗ 1 - получатель потока затрат стоимостью 375 руб. и количеством 1 штука
• ЦЗ 0 - источник потока затрат

Объект учета ЦЗ 0 не имеет никаких свойств. Такие центры затрат можно рассматривать в качестве своебразных «заглушек», используемых в тех случаях, когда в регистр накопления УчетЗатратРегл поступают потоки затрат от объектов учета, не являющихся центрами затрат.

В теории Графов затрат такие потоки затрат называются потоками первичных затрат . Основная особенность таких потоков затрат заключается в том, что их стоимости должны быть известны до(!) начала процедуры закрытия затрат. Стоимость потока первичных затрат может быть определена на основании первичных учетных документов - накладных, актов приема-передачи, счетов-фактур и т.д., а также может определяться расчетным путем (ФИФО, ЛИФО, по средней) - в случае списания в производство материально-производственных запасов со складов предприятия.

В нашем примере поток первичных затрат поступает от объекта учета - расчеты с контрагентом Вектор по Договору 1, учитываемые на счете бухгалтерского учета 60.21 , не являющегося центром затрат . Поскольку регистр накопления УчетЗатратРегл не предназначен для работы с такими объектами учета, этот объект учета заменяется «заглушкой» в виде центра затрат ЦЗ 0 без свойств. Стоимость этого потока затрат должна быть известна «сразу» - из соответствующего первичного учетного документа, т.е. эту стоимость не требуется определять во время процедуры закрытия затрат в конце рассматриваемого периода.

Рассмотрим подробнее свойства объекта учета ЦЗ 1 , принадлежащего классу МПЗ :

Для идентификации данного центра затрат в регистре накопления УчетЗатратРегл задействовано всего только 5 аналитик из 29 возможных к применению:

• Раздел учета =МПЗ
• Организация =Одуванчик
• Склад =Склад цеха №2
• Счет учета =10.05
• Затрата =Инжектор

В результате проведения данного документа в регистре накопления УчетЗатратРегл :

• появился новый ЦЗ2 , получивший поток затрат в количестве 1 штука
• ЦЗ1 является источником потока затрат

Теперь в регистре накопления УчетЗатратРегл появилась пара «настоящих» центров затрат - ЦЗ 1 (источник) и ЦЗ 2 (получатель). Эти центры затрат обменялись между собой потоком вторичных затрат, причем, оценить этот поток вторичных затрат мы можем пока только количественно. Стоимость потока вторичных затрат будет известна после проведения документа Расчет себестоимости выпуска, т.е. после выполнения процедуры закрытия затрат.

Сразу оговоримся, что мы сейчас рассматриваем теорию вопроса. На практике (в т.ч. и в подсистеме РАУЗ) пользователи иногда хотят иметь хоть какие-то оценки потоков вторичных затрат до проведения процедуры закрытия затрат. Для этого в течение периода предусматривается проведение «принудительной» оценки стоимостей потоков вторичных затрат по каким-либо правилам, например, исходя из плановых значений себестоимости. Мы не будем обсуждать здесь, насколько могут быть полезны (и точны) для пользователей такие оценки стоимости потоков вторичных затрат, все равно в конце периода эти стоимости будут заменены фактическими значениями (или доведены до фактических значений с помощью корректировок), полученными в результате решения СЛАУ.

Стоимостная оценка потока затрат появится после проведения документа Расчет себестоимости выпуска в конце рассматриваемого периода:

На основе данных регистра накопления УчетЗатратРегл мы можем построить хотя и маленькую, но уже полноценную затратную модель предприятия - Граф затрат:

В данном случае мы смогли наглядно отобразить процесс движения потоков затрат в Графе затрат предприятия Одуванчик, но мы уже говорили выше о том, что предложенная разработчиками подсистемы РАУЗ технология формирования центров затрат из аналитик приводит к тому, что реальный Граф затрат может быть сформирован десятками и даже сотнями тысяч центров затрат. С таким Графом затрат разобраться будет неизмеримо сложнее, если вообще возможно.

Уравнение баланса затрат для центра затрат в подсистеме РАУЗ ()

В процессе проведения на предприятии процедуры закрытия затрат в конце периода мы должны для каждого центра затрат ЦЗ i из регистра накопления УчетЗатратРегл (они еще называются - узлами) решить две задачи:

• задача 1 - собрать все затраты, поступившие на вход центра затрат ЦЗ i
• задача 2 - распределить затраты с выхода центра затрат ЦЗ i на входы других центров затрат

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

Шаг 1 . Определяем общее число единиц калькуляции K i IN , поступившее в рассматриваемом периоде на вход центра затрат ЦЗ i :

где :

• K i BEG - количество единиц калькуляции в ЦЗ i на начало периода
• K i CAP - общее количество единиц калькуляции, поступившее в рассматриваемом периоде на вход ЦЗ i
• K k,i - количество единиц калькуляции, поступившее в рассматриваемом периоде на вход ЦЗ i ЦЗ k

Шаг 2 S i IN , поступивших в рассматриваемом периоде на вход центра затрат ЦЗ i :

где :

• Si BEG - стоимость затрат в ЦЗi на начало периода
• Si CAP - общая стоимость затрат, поступивших в рассматриваемом периоде на вход ЦЗi от центра затрат - «заглушки»
• Sk,i - стоимость затрат, поступившая в рассматриваемом периоде на вход ЦЗi от корреспондирующего центра затрат ЦЗ k

В данном случае стоимость S k,i

S k,i = K k,i × t k

где :

• K k,i ЦЗ k на вход ЦЗ i
• t k - тариф, т.е. ЦЗk

Шаг 3 . Определяем общую стоимость затрат S i OUT на выходе центра затрат ЦЗ i :

Стоимость поступивших с выхода ЦЗi на вход ЦЗp вторичных затрат Si,p представлена следующим образом:

Si,p =Ki,p ×ti

где :

• Ki,p - количество единиц калькуляции, переданных с выхода ЦЗi на вход ЦЗp
• ti - тариф, т.е. стоимость одной единицы калькуляции на выходе центра затрат ЦЗi

Поскольку количество единиц калькуляции K i,p предполагается известным, для определения стоимости S i,p нам необходимо найти значение t i . Разработчики подсистемы РАУЗ предложили для поиска значения t i использовать уравнение вида:

Для удобства проведения вычислений в подсистеме РАУЗ перепишем уравнение в следующем виде:

Известные до начала решения СЛАУ величины предполагается хранить в ресурсах (*) регистра сведений УзлыКорректировкиСтоимостиСписания :

* Это технологическая информация, она может быть изменена разработчиками

Мы не будем далее рассматривать саму процедуру решения СЛАУ, т.к. она довольна проста и не содержит каких-либо методологических «изысков». Мы лучше поговорим о том, каковы последствия использования того вида уравнения, которое предложили разработчики РАУЗ.

Здесь необходимо обратить внимание на тот факт, что в знаменателе формулы для определения значения t i содержится общее количество единиц калькуляции K i IN на входе(!) центра затрат ЦЗ i . Именно на входе, а не на выходе ЦЗ i , как можно было бы предположить!

В теории Графов затрат подобный подход к составлению уравнений используется только для строго определенных (частных) случаев. Например, подобным образом можно составлять уравнения для центров затрат , предназначенных для учета стоимости продукции на складах предприятия. Другими словами, этот подход к составлению уравнения применяется для той части центров затрат в модели предприятия, в которой происходит движение готовой продукции между складами предприятия. В общем случае предполагается, что необходимо опираться на количество единиц калькуляции, ушедших с выхода(!) центра затрат ЦЗi на входы других центров затрат.

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

Уравнение баланса затрат для центра затрат

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

• на входе центра затрат должен присутствовать только(!) один вид единиц калькуляции - как при поступлении первичных затрат, так и при поступлении вторичных затрат
• вид единицы калькуляции на выходе центра затрат должна совпадать(!) с видом единицы калькуляции на его входе

Данные условия очень серьезно ограничивают варианты использования центров затрат в модели предприятия. Выполнение этих условий является логичным только для центров затрат, представляющих собой продукцию на складах предприятия, когда имеет смысл составлять уравнение баланса затрат как для стоимости потоков затрат - входящих и исходящих из центра затрат, так и для их количества. В терминологии подсистемы РАУЗ выполнение данных условий логично использовать для центров затрат, относящихся к РазделУчета =МПЗ . Распространение же этих условий на центры затрат из других разделов учета является весьма странным решением, т.к. в модели предприятия может существовать (и существует на самом деле) большое число центров затрат, у которых:

• на входе присутствуют различные виды единиц калькуляции
• виды единиц калькуляции на выходе центра затрат не совпадают с видами единиц калькуляции на его входе

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

В данном случае на входе и на выходе центра затрат единицей калькуляции является - 1 штука (инжектор). Причем, эта единица калькуляции не равна, например, единице калькуляции 1 штука (гайка), 1 штука (болт) и т.п. Для того, чтобы единицы калькуляции можно было назвать равными, необходимо обеспечить совпадение не только единиц измерения, в нашем примере - 1 штука, но и совпадение других характеристик единицы калькуляции, в нашем примере это номенклатурные признаки инжектора.

Для «продвинутых» пользователей-методологов РАУЗ ( )

Продвинутым пользователям-методологам подсистемы РАУЗ возможно будет интересно узнать, что рассмотренная в предыдущем разделе статьи формула для расчета стоимости единицы калькуляции t i на выходе центра затрат ЦЗ i работает не для всех центров затрат, содержащихся в регистре накопления УчетЗатратРегл . Это обусловлено тем, что даже в той модели предприятия, которую предложили сами разработчики подсистемы РАУЗ, не для всех центров затрат им удалось обеспечить выполнение условий, накладываемых на использование единиц калькуляции на входах и выходах центров затрат, а именно:

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

Поскольку настоящая публикация носит научно-популярный характер, мы не будем сильно углубляться в данный вопрос. Обратим только внимание пользователей на то, что в результате проведения документа Расчет себестоимости выпуска могут появиться, например, такие ситуации:

Данный фрагмент Графа затрат моделирует следующую хозяйственную операцию в подсистеме РАУЗ - из купленных материалов Гайка М10 (1 штука) и Доска (1 штука) в Цехе 2 была произведена продукция - Полка мебельная БП1 (1 штука).

На входе центра затрат ЦЗ 3 присутствуют три вида единиц калькуляции:

• Гайка М10 (1 штука) - поступила с выхода ЦЗ 1
• Доска (1 штука) - поступила с выхода ЦЗ 2
• Полка мебельная БП1 (1 штука) - поступила с выхода ЦЗ 0

На выходе центра затрат ЦЗ 3 единицей калькуляции является - Полка мебельная БП1 (1 штука), поступившая на вход центра затрат ЦЗ 4 .

Как видим, для центра затрат ЦЗ 3 не выполняется ни одно из требуемых условий:

• на входе ЦЗ 3 присутствуют не один, а три вида единиц калькуляции
• вид единицы калькуляции на выходе ЦЗ 3 не совпадает с видом единицы калькуляции на его входе

Почему разработчики РАУЗ допустили такую ситуацию? И как они из нее выходят?

Начнем с ответа на второй вопрос для чего рассмотрим фрагментарно работу регистра накопления УчетЗатратРегл при проведении документа Расчет себестоимости выпуска:

Анализ записей регистра позволяет сделать вывод о том, что разработчики РАУЗ поступили следующим образом:

• ВидДвижения =Расход - затраты от ЦЗ 1 к ЦЗ 3
• ВидДвижения=Приход - затраты от ЦЗ1 к ЦЗ3
• ВидДвижения =Расход - затраты от ЦЗ2 к ЦЗ3 передаются в стоимостной и количественной оценке
• ВидДвижения=Приход - затраты от ЦЗ2 к ЦЗ3 передаются только(!) в стоимостной оценке

т.е. подсистема РАУЗ «жестко» вмешалась в общий порядок процедуры составления системы уравнений и просто подавила Количество для приходных движений на центр затрат ЦЗ 3 .

Движения регистра УчетЗатратРегл , характеризующие передачу потока затрат с выхода ЦЗ 3 на вход ЦЗ 4 , формируются документом Расчет себестоимости выпуска: ЦЗ 3 нельзя использовать формулу из предыдущего раздела статьи.

Теперь попытаемся понять, почему разработчики подсистемы РАУЗ допустили существование подобной ситуации в модели предприятия? Возможно, наличие подобных ситуаций является результатом недостаточно глубокой проработки методологических вопросов на этапе создания подсистемы РАУЗ. В данном случае это выразилось в попытке распространить частный вариант составления уравнения баланса затрат, применяемый для класса центров затрат, моделирующих продукцию на складах предприятия, на все остальные классы центров затрат. Как и следовало ожидать, общее оказалось сложнее частного.

Следует отметить, что это не единственный методологический «ляп» подсистемы РАУЗ. Другой, гораздо более серьезный методологический «ляп», связанный с организацией учета МПЗ для случая, когда используется метод ФИФО (РАУЗ) для оценки стоимости МПЗ при их списании в производство, мы рассмотрим в статье ФИФО (РАУЗ) - работает или не работает? .

ВЫВОДЫ ()

Так чего же больше в подсистеме РАУЗ - технологических нововведений, связанных с оптимизацией структуры метаданных, или революционных идей в области методологии учета затрат? Если сравнить объем изменений в структуре метаданных (и технологию работы с данными) с объемом методологических новаций, введенных разработчиками подсистемы РАУЗ в 1С УПП, то за явным преимуществом, безусловно, победу одержит технология.

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

решение налоговых задач на Графах затрат

решение обратных задач (в частности - задачи финансового планирования) на Графах затрат

задачи формирования топологии Графа затрат

и т.п.

Кроме того, наличие огромного количества центров затрат (узлов) в реальных регистрах накопления УчетЗатратРегл совсем не означает, что у пользователя появляется огромное количество дополнительной аналитики, необходимой для целей финансового управления предприятием. Не следует путать объем технологических учетных данных с объемом учетных данных, из которых можно извлечь действительно полезную информацию.

Какой же основной вывод можно сделать из вышеизложенного? С одной стороны, хотелось бы посоветовать разработчикам более глубоко изучать модель предметной области, с которой они имеют дело при разработке автоматизированной системы. С другой стороны, разработчиков подсистемы РАУЗ можно поблагодарить уже хотя бы за то, что теперь специалисты по расчету себестоимости просто вынуждены обсуждать методологию учета затрат, основанную на использовании математической модели предприятия в виде Графа затрат. Без подсистемы РАУЗ обсуждать данные вопросы было бы значительно сложнее, а обсуждать их крайне необходимо. В настоящее время наблюдается какое-то вторичное отношение к методологии учета вообще, и к методологии учета затрат в частности. Складывается ощущение, что учетных специалистов охватила какая-то «методологическая» апатия, изучение методологии учета отодвигается (и даже - задвигается) на второй план, а все силы бросаются на изучение постоянно изменяющихся технологических особенностей автоматизированных систем.

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

Несколько слов обязательно нужно сказать также об использовании в подсистеме РАУЗ систем линейных алгебраических уравнений (СЛАУ). В настоящее время этот вопрос все еще почему-то относится к категории «продвинутых» методологических вопросов и довольно часто формулируется даже следующим образом - а нужно ли вообще использовать СЛАУ для расчета себестоимости? Не слишком ли это сложно?

Что тут можно ответить? Даже как-то неудобно иногда становится за вполне квалифицированных специалистов по расчету себестоимости, серьезно обсуждающих достоинства и недостатки различных(!?) способов закрытия затрат - прямого, пошагового или с помощью СЛАУ . По каким-то причинам специалисты по расчету себестоимости до сих пор спорят по этому вопросу, несмотря на то, что обязательным условием корректного закрытия затрат (способ не имеет значения) является именно выполнение уравнений баланса затрат для каждого центра затрат или в традиционном понимании - счета учета. Это значит, что в процессе закрытия затрат СЛАУ должны составляться и решаться всегда! Только иногда это происходит в явном виде - например, как в подсистеме РАУЗ, а иногда - в завуалированной форме, когда процесс закрытия затрат принимает некий туманный вид, скрывающий главный смысл этого процесса.

Пользователям подсистемы РАУЗ автор также настоятельно рекомендует ознакомиться с теорией вопроса, касающегося особенностей расчета стоимостей потоков встречных затрат, т.к. с очень большими стоимостями встречных потоков затрат при закрытии затрат в РАУЗ рано или поздно сталкиваются все (если, конечно, обращают на это внимание). По этой теме можно посмотреть видеоролик 7.Графы затрат. Встречные потоки затрат и прочитать статьи:

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

Для общего понимания ситуации, можно порекомендовать следующие статьи:

• Онтологии в микроэкономике (ч.1). Введение - в настоящее время одним из главных трендов во многих областях человеческой деятельности является переход от хранения и обработки данных к хранению и обработке знаний, что выражается, например, в создании экспертных систем. Существуют различные варианты формализации знаний о предметной области, одним из быстро развивающихся направлений является онтологический способ представления знаний. Современные стандарты (МСФО, НСБУ) бухгалтерского учета предполагают использование многочисленных экспертных оценок при составлении бухгалтерской отчетности, не предлагая экспертам в области учета строгой формальной системы общепризнанных ключевых понятий. Все это делает разработку онтологий для бухгалтерского учета архиважной задачей 2.Графы затрат. Центры затрат

Я убежден, что если бухгалтер не может справится с той или иной программой — это на 90% вина разработчика.

Расчет себестоимости в УПП (РАУЗ) реализован очень сложно. Научить большинство бухгалтеров квалифицированно использовать РАУЗ практически невозможно. Потому я пошел по пути упрощения процедуры расчета.

Я создал обработку, которая выполняет:

1) Заполнение регистра сведений «Способы распределения статей затрат организаций»
Для меня весьма удивительно, что фирма 1С считает бухгалтеров достаточно квалифицированным для заполнения регистра «Способы распределения статей затрат организаций», реализующего сложную математическую модель для расчета себестоимости. Я уверен что любой бухгалтер даже после четких и правильных указаний как заполнять регистр будет периодически забывать указывать в нем новые статьи затрат. Типовое же заполнение этого регистра из документа «Расчет себестоимости» показался мне бессмысленным. Потому я реализовал заполнение регистра программно по согласованному с учетной политикой (читай глав. бухом) алгоритму. Вероятность ошибки его заполнения становится равна нулю. В моей обработке указано распределять все нематериальные расходы по всем подразделениям. Материальные расходы — не распределять. Правила заполнения сможет изменить любой программист.

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

3) Корректирует плановую себестоимость
Программа проанализирует среднюю закупочную цену каждого ТМЦ, приобретенного в текущем месяце и создаст документ «Установка цен номенклатуры» в начале месяца с этой ценой. Затем обработка перепроведет все документы расхода ТМЦ.

Возможно это тоже покажется многим не обязательным, но что вы отвечаете на вопрос бухгалтеров о том что списание ТМЦ у них в любимых проводках делается только количеством и нет сумм списания? И как результат крайне неудобно работать с бухгалтерскими отчетами, как ОСВ или карточка счета. Лично я для ответа на такой вопрос настроил политику списания ТМЦ по «Плановой цене», и говорю бухгалтерам лишь о необходимости выполнить расчет себестоимости моей обработкой. После этого они увидят суммы списанных ТМЦ в проводках. Да, конечно это будут приблизительные суммы, без учета доп. расходов, но все же это будет близкие к правде суммы, помогающие видеть общую картину.

4) Убирает аналитику распределения затрат в документе «Отражение зарплаты в регл. учете»
Так уж получилось что Кадровик периодически указывает в шаблонах начислений ЗП аналитику распределения затрат. В нашем случае ее использование абсолютно не нужно, потому вместо того что бы пинать кадровика/расчетчика я создал процедуру очистки этой аналитики в документах «Отражение зарплаты в регламентированном учете». Овцы целы, волки сыты!!!

5) Заполняет номенклатурную группу в документах движения МПЗ.
К сожалению, сколько людей не учи, они будут периодически делать ошибки. В частности будут забывать заполнять реквизит «Номенклатурная группа» в табличных частях документа. В результате о корректном расчете себестоимости не может быть и речи. Я создал процедуру, которая автоматически проверяет заполнение реквизитов в табличных частях документов, и если они пустые — заполняет значением из карточки товара. Если номенклатурная группа не указана и в карточке товара — обработка громка об этом закричит и заставит все же заполнить нужные реквизиты.

6) Выполняет корректировку документов «Отчет производства»

Выполняется очень простая корректировка. В нашем производстве изготавливается много однотипной продукции с разными параметрами. Например в документе Отчет производства указано что изготовили 1 тонну кирпича красного и 100 тонн кирпича белого. Для этого было израсходовано материалов 1 тонна красной глины и 100 тонн белой глины. Как программа распределит материалы по продукции??? Если вы не заполнили колонку вес в табличной части Продукция, то программа половины глины красной и белой распределит на первую продукцию и половину красной и белой глины — на вторую продукцию. Таким образом себестоимость красного кирпича будет на два порядка больше себестоимости белого (при условии равенства цен на красную и белую глину). А в отчете по производству вы обнаружите, что в составе белого кирпича используется белая глина, а в составе красного кирпича — белая глина. Важно сделать оговорку — этот бардак происходит, если вы не указали спецификацию. В большинстве случаев — спецификация действительно заполняется. Но все же бывают и исключения!
Моя обработка заполняет вес в строках выпуска равным количеству выпуска.

7) Убирает аналитику распределения затрат в «Актах производственных услуг»
Опять же вместо того что бы заставлять материалиста следить за тем что бы реквизит был пустым — проще его автоматически чистить перед расчетом себестоимости.

8) Выполняет проверку возможности «полного закрытия» материальных затрат.

Этому фокусу меня научил очень грамотным специалист из фирмы Директ-Проект (Волгоград) — Ирина. Дело в том что обычно списание материальных затрат мы делаем либо согласно документам «Инвентаризация незавершенного производства», либо дополнительного списания (кроме документов расхода в течение месяца) не делается. Теоретически и в первом и втором случае, при достижении количественного остатка нулевого значения программа должна списывать всю его себестоимость. Но это не всегда происходит и выясняется это слишком поздно. Потом предложено перед основным расчетом себестоимости изменять настройку регистра «Способы распределения статей затрат организаций» так что бы все материальные расходы распределялись полностью и одновременно помечать на удаление документ «Инвентаризация незавершенного производства». Если все в программе хорошо — то после расчета себестоимости — все материальные расходы должны быть списаны в 8. Но на практике это не всегда получается и нужно оперативно на это реагировать.

Моя обработка перезаполняет регистр сведений «Способы распределения статей затрат организаций» таким образом что бы все материальные затраты распределялись, затем помечает на удаление документы «Инвентаризация незавершенного производства» и после расчета себестоимости проверяет, что бы остаток затрат оказался нулевым. Если этого не происходит — мы заставляем пользователя изучить отчет «Ведомость по затратам» и устранить причины «зависшей» себестоимости. Если же удалось закрыть регистр затрат в ноль, то обработка снова меняет регистр сведений «Способы распределения статей затрат организаций» на принятую учетной политикой систему, снимает пометки проведения с документов «Инвентаризация незавершенного производства» и переходи к главному событию (ради которого все начали)- расчету себестоимости.

9) САМОЕ ГЛАВНОЕ!!! В случае, если проведение штатного документа «расчет себестоимости» сообщает об наличии «отрицательных остатков» — моя обработка откажется проводить документ расчета себестоимости и покажет подробно — какие отрицательные остатки надо исправить!

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

Для поиска этих «отрицательных остатков» необходимо:

• Формировать два разных отчета («Ведомость по затратам» и «Ведомость по учету МПЗ»);
• Настроить достаточно подробную детализацию (иногда 5-7 группировок) Например, обязательно включить детализацию по номенклатурным группам, что бы увидеть, что остатки по одной группе +1, а по другой -1 (пересортица);
• Обязательно распровести документ "Расчет себестоимости";
• Хорошо уметь пользоваться прочими настройками и режимами отчета.

Моя обработка не только громко закричит о наличие отрицательных затрат и не позволит проводить документ, если таковые имеются, но и покажет какой отчет надо сформировать (будет выделен красным цветом). Кроме того в каждом отчете уже будет выполнена настройка группировок, что бы наверняка увидеть отрицательные остатки в случае пересорта и (!!!) будет включен отбор по МПЗ или Затрате. Таким образом искать придется не в 10 страничном отчете, а, как правило, в отчете из 4-20 строк, в которых половина — положительные остатки, а половина — отрицательные. Сравнив две строки — сразу понятно, по какому реквизиту (склад, номенклатурная группа или пр.) возник пересорт.

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

ИГОРЬ ЧУФАРОВ , начальник ИТ-отдела ООО «Кыштымский огнеупорный завод», [email protected]

РАУЗ в 1С – друг или враг?
Часть 1. Развенчание мифов и поиск правды

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

Rein raus.

Припев одноименной песни группы Rammstein

Так ли страшен черт?

Несмотря на уже солидную историю, режим расширенной аналитики учета затрат (РАУЗ) в программах 1С до сих пор вызывает множество споров и противоречивых мнений. Для многих бухгалтеров его название звучит так же угрожающе, как брутальные строки из песни, вынесенной в эпиграф.

Да и, чего греха таить, многие специалисты 1С до сих пор считают РАУЗ неким сферическим конем в вакууме, черным ящиком, шайтан-машиной. Например, из разговора с одним из сотрудников франчайзи-фирмы «1С», я узнал, что отдел поддержки клиентов у них занимается сопровождением, только если не используется расширенная аналитика. В противном случае поддержку осуществляет отдел разработки – с более квалифицированными сотрудниками, готовыми решать сложные задачи. Это о чем-то да говорит!

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

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

Историческая ретроспектива

РАУЗ появился начиная с версии «Управление производственным предприятием 1.2.15». Стоит отметить, что с самого начала расширенная аналитика позиционировалась как приоритетный режим; рекомендовалось подготавливать и осуществлять переход; сообщалось, что все дальнейшее развитие функционала будет осуществляться исключительно под него.

Более того, если процедура перехода с партионного учета на РАУЗ является штатной и достаточно подробно описана , то обратный переход стандартными средствами системы невозможен (если быть точным, то возможна отмена перехода на РАУЗ, но при этом требуется полное перепроведение всех документов; нет и речи о том, чтобы перейти на партионный учет с определенной даты, как это происходит при включении расширенной аналитики).

Главная особенность режима – учет себестоимости всех запасов и затрат ведется только в двух регистрах «Учет затрат (бухгалтерский и налоговый учет)» и «Учет затрат (управленческий учет)». Это касается запасов в производстве и на складе, производственных и непроизводственных затрат, выпуска продукции и структуры ее себестоимости. Ведь принципиальной разницы с методологической точки зрения между запасом и затратой нет.

Получается, что практически вся информация о производственной деятельности предприятия учитывается только по двум регистрам. Но как тогда удается отследить, на какой стадии в данный момент находятся затрата или запас? Ведь, как уже неоднократно было сказано, в разные моменты времени одна и та же сущность может быть как запасом (в момент, когда она находится на складе), так и затратой (когда передана в производство).

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

Казалось бы, к чему такие усложнения? Однако сделано все это не зря, так как обратной стороной использования ключей является упрощение добавления собственных аналитик, которых изначально не было в УПП. Поскольку себестоимость рассчитывается для ключей, а не отдельных аналитик, при этом не будет необходимости переписывать алгоритмы проведения по регистрам первичных документов и расчета себестоимости.

Одна из основных задач, которую РАУЗ призван был решить, – обеспечение корректности учета при нарушении хронологии ввода первичных документов. Дело в том, что окончательная картина в данном случае складывается по завершении месяца, и неважно, в каком порядке вводились документы изначально. Например, требование-накладная о передаче материала в производство может быть оформлено раньше, чем его поступление на склад. Главное, чтобы все это было внутри одного месяца.

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

Например, не единожды сталкивался с тем, что организации ведут учет ручными проводками просто потому, что не могут оперативно восстанавливать последовательность документов, а значит, закрывать месяц с помощью регламентных операций. Это, конечно, ужасно. При таком раскладе РАУЗ реально поможет «цивилизовать» ситуацию относительно малой кровью. Более подробную информацию об этом и других парадоксах учета в 1С вы можете почерпнуть из .

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

Следующий момент, который был заявлен как серьезное улучшение, – автоматический расчет встречного выпуска. Если на производстве практикуется циклическое использование выпущенной продукции в качестве сырья (например, брак выпуска кирпича перемалывается до состояния глины и используется при формовке новых изделий), если распространено взаимное оказание услуг подразделениями (транспортный цех подвозит уголь в котельную, которая отапливает транспортный цех), то РАУЗ будет просто спасательным кругом. Одним словом, достоинств режима предостаточно, для некоторых организаций он просто незаменим.

Статью целиком читайте в журнале «Системный администратор», №3 за 2014 г. на страницах 39-45.

Круг и масштаб задач, решаемых на платформе 1С, растет с каждым годом. Появляются новые инструменты и методики, зачастую, не побоимся этого слова, революционные.

Такой когда-то стала и расширенная аналитика учета затрат - РАУЗ.

Выпустив в одном решении РАУЗ в качестве альтернативы партионному учету, фирма 1С отдала на откуп внедренцам право выбора использования одного из этих механизмов. Конечно, изначально страдавший «детскими болезнями» (ни для кого не секрет, что этим страдают все принципиально новые решения, и не только у 1С этим грешат), РАУЗ с опаской воспринимался как некая «шайтан-машина». Но в целом, попав на благодатную почву проблем, которые испытывали и пользователи и внедренцы при решении сложных и масштабных задач учета себестоимости, он был быстро признан теми, для кого важен не только результат, но и способ его достижения.

Несмотря на это, часть людей (к счастью, небольшая), в особенности со стороны специалистов по внедрению, так и остались во власти стереотипов и продолжают упорно скрещивать копья в битве за традиционный партионный учет. Какие же доводы приводятся в защиту этой позиции? Следует отметить, что борьба идет, в основном, за метод ФИФО, списание по среднему окончательно сдано в архив:

«Партионный учет прозрачнее и правильнее» - главный аргумент консерваторов. Вполне можно вручную рассчитать каждый показатель, увидеть историю его формирования по первичным документам. Действительно, с этой точки зрения партионная методика ФИФО, разработанная фирмой 1С, просто великолепна, но какова цена этой красоты?

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

В РАУЗе нужно привыкнуть «доверять» программе, и принять ФИФО с точки зрения той логики, которая в нее заложена. На нашей памяти генеральный директор одной торговой компании с большим оборотом и ассортиментом товара лично (!), с подозрением и скепсисом во взгляде, на калькуляторе пересчитывал вслед за программой себестоимость товара. Через пару месяцев, не найдя никакого «криминала» в результатах, он успокоился и полностью доверил программе эту трудоемкую работу.

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

На этом аргументация в пользу «традиционки» заканчивается, поговорим серьезно о «трех китах», на которых стоит методология применения РАУЗ.

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

Второй - точность. Многие не согласятся, однако сделаем оговорку: мы рассматриваем не только торговые организации, но и производственные, где для бизнеса единственным способом получить производственные отчеты со сложными итерационными бизнес-процессами будет использование РАУЗ (вспомним: встречный выпуск, многопередельное производство и т.п.)

Третий - гибкость и прослеживаемость движения. Это и возможность настройки глубины аналитики без существенной потери производительности (думаем, эксперты в архитектуры платформы понимают, о чем идет речь), и выбор параллельного/совместного ведения УУ и БУ. А самое главное - двойная запись, без которой в «традиционке» сумма может взять и «потеряться» на полпути между многочисленными регистрами.

Какие же выводы можно сделать? Безусловно, технология РАУЗ весьма перспективна, приносит существенные выгоды в сложном учете, отлажена и имеет солидный багаж успешных внедрений. К недостаткам следует отнести, в первую очередь, слабую отчетность и отсутствие удобных пользовательских инструментов анализа. Кроме того, технология еще достаточно молодая, специалистов и методических материалов мало, значительная часть сообщества настроена относительно консервативно. Кроме того, всегда находятся задачи, в которых без применения партионного учета не обойтись, например, если ведение расчетов по налогам жестко связано с учетом товаров (кассовый метод НДС).

Перефразируя известную шутку, можно сказать - вам не нравится РАУЗ? Вы просто не умеете его готовить.