Обоснование концепции системы АУБ (Автоматизация Управления Бизнесом) для автоматизации управленческого учета (УУ) многопрофильного холдинга (МХ) на платформе 1С
Содержание:
1. Обзор подходов к реализации/доработке функционала УУ на платформе 1С
1.1.Расширение типового функционала конфигурации используемой для регламентированного учета (РУ) для целей УУ
1.2.Использование доработанной типовой конфигурации в отдельной базе данных (БД) только для целей УУ
1.3.Конфигурация разрабатывается «с нуля» для УУ ("самописка") и используется в отдельной БД только для УУ
1.4.Разрабатывается отдельная линейка объектов для автоматизации УУ, функционал УУ представляет дополнительный модуль к типовому решению, используемому для РУ, типовые объекты конфигурации не модифицируются
2.Концепция автоматизации в системе АУБ
2.1.Подход к разработке функционала УУ
2.2.Интеграция УУ и РУ в АУБ
2.3.Уровни автоматизации и стратегические центры ответственности (СЦО) в АУБ
2.4.Порядок бизнес планирования в АУБ
2.5.Номенклатура в АУБ
2.6.Аналитики и функционал экономического уровня в АУБ
2.7.Учетные цены, отклонения и себестоимость в АУБ
2.8.Объекты имущества в АУБ
2.9.Зарплата в УУ АУБ
2.10.Учет сделок, оперативное планирование и взаиморасчеты по сделкам в АУБ
2.11.Этапы развития автоматизации УУ СЦО в АУБ
3. Автоматизация оптимизации налогообложения (АОН)
3.1.Задачи АОН
3.2.Подход к функционалу АОН
3.3.Примеры сервисов АОН
1. Обзор подходов к реализации/доработке функционала УУ на платформе 1С
В задачах автоматизации управления бизнесом на платформе 1С часто возникает необходимость в доработке типовых конфигураций, либо вообще разработке функционала «с нуля». Понятно, что любая модификация типового решения несет в себе много проблем, но в случае значительной отраслевой специфики бывает, что без нее нельзя никак обойтись.
Если для начала учетного процесса предприятия используют типовое решения, то впоследствии, для более полной поддержки управленческих решений, многие идут на доработки типового функционала.
На этом пути сформировались четыре основных подхода имеющих свою специфику.
1.1.Расширение типового функционала конфигурации используемой для регламентированного учета (РУ) для целей УУ
1.1.1.В данном подходе источником для принятия управленческих решений являются данные РУ. РУ совмещает для предприятия роль управленческого и регламентированного учетов. УУ при этом представляет некоторый дополнительный набор сервисов. УУ не является полнофункциональным учетом, т.е. отражающим управленческую прибыль, баланс и т.д.
1.1.2.Притягательностью этого подхода является легкость, с которой может достигаться «управленческий» учет, т.к. РУ предприятие вести обязано, поэтому он всегда есть, и небольшой доработкой достигается функционал затребованный предметниками для управления.
1.1.3.Но у этого подхода есть два больших и неразрешимых недостатка.
1.1.3.1.РУ постоянно обновляется в типовых конфигурациях 1С, обновления бывают по несколько раз в месяц и отказаться от обновления типового функционала РУ нельзя, иначе он потеряет актуальность. Поэтому постоянно стоит задача сопряжения этих доработок с обновлениями РУ. В случае больших доработок, необходимых для отражения значительной отраслевой специфики, с существенными изменениями архитектуры данных, обновление становится слишком трудоемким («хождение по мукам») и команда разработчиков, в конце концов, теряет контроль над функционалом. Работа конфигурации становится не стабильной, функциональность непредсказуемая и малопригодная как для РУ, так и для УУ. Как правило, при этом меняется команда программистов, и новые разработчики, от которых Заказчик/Работодатель ждет «чудо исправления», вообще не в курсе что там «понакодили» их «предшественники». Опыт показывает, что те кто идет по этому пути, в течение 1-2 лет производят «полный перезапуск» своей автоматизации, начиная все опять по новой.
1.1.3.2.Подход, когда источником для принятия управленческих решений являются данные РУ, не совместим со сложной налоговой оптимизацией, при которой процесс оформления деятельности «расписывается» на несколько организаций, а реальные учетные события дополняются виртуальными чисто оформительскими событиями.
1.1.4.В целом этот подход можно рассматривать лишь как временное решение учетных проблем в части УУ, но для долгосрочного решения в автоматизации управления предприятием он не годится. Для долгосрочного решения предприятию, с существенной отраслевой спецификой, для целей управление нужно иметь «свое» решение, которое не связано ни с проблемами обновления РУ, ни с оптимизацией оформления деятельности в части РУ. Практика показывает, что когда такое решение у предприятия появляется, оно может потом работать и развиваться многие годы, удовлетворяя потребности бизнеса в эффективном управлении.
1.2.Использование доработанной типовой конфигурации в отдельной базе данных (БД) только для целей УУ
1.2.1.В этом подходе, как правило, за базу используется «тяжелое» типовое решение 1С (например, УПП или ERP). Это связано с желанием иметь сразу «побольше» полезного функционала и ожиданием, что раз много учетных проблем уже решено в типовой конфигурации, то трудоемкость необходимых для отражения отраслевой специфики доработок будет незначительной.
1.2.2.Следует признать, что по сравнению с подходом п.1.1. здесь нет той остроты, вызванной необходимостью оперативно обновлять типовой функционал РУ (п.1.1.3.1.), т.к. базовое типовое решение 1С, используемое в этом случае только для УУ, не обязано обновляться.
1.2.3.Однако, в случае больших доработок, необходимых для отражения значительной отраслевой специфики, с существенными изменениями архитектуры данных, их трудоемкость слишком велика. Это вызвано сложностью «тяжелого» типового решения и наличие в нем функционала отражения РУ не нужного для УУ, но который должен учитываться в доработках.
1.2.3.1.При значительных отраслевых доработках типового функционала, более целесообразным в этом подходе видится использование за базу более «простых» типовых решений (например, УНФ или УТ). Но это все равно достаточно сложные решения, изначально спроектированные без учета отраслевой специфики предприятия.
1.2.3.2.Этот подход можно сравнить с переоборудованием уже готового здания под другое целевое назначение. Понятно, что чем сложнее и больше это здание и чем менее оно подходит для новой цели его использования, тем сложнее и опаснее будет его переоборудование. Так же понятно, что во многих случаях, легче и надежней будет построить новое здание «с нуля».
1.2.4.Кроме этого возникает вопрос интеграции данных УУ и РУ, он осложнен тем, что это разные БД, а в учетных событиях часто необходимы «онлайн» данные из РУ, соответственно нужен «онлайн» функционал синхронизации данных и обменов решений УУ и РУ.
1.2.4.1.Но главной проблемой интеграции УУ и РУ в этом случае видится сложность синхронизации данных и ее не совместимость со сложной налоговой оптимизацией, когда фактическая деятельность «расписывается» на несколько организаций, а реальные учетные события зачастую меняют свой смысл и интерпретацию для оформления деятельности в РУ.
1.2.5.Этот подход можно использовать при небольшой отраслевой доработке типовой конфигурации и при незначительной налоговой оптимизации. В многопрофильном холдинге, с учетом потребности в консолидации и бизнес планировании, использовать этот подход для составляющих направлений бизнеса (предприятий) видится нецелесообразным. Эффективная корпоративная система, если она создана, может потом работать и развиваться многие годы, удовлетворяя потребности бизнеса, и в крупной бизнес структуре стоит побороться за ее создание.
1.3.Конфигурация разрабатывается «с нуля» для УУ ("самописка") и используется в отдельной БД только для УУ
1.3.1.Главным преимуществом этого подхода является его «отвязка» от какой либо готовой функциональности и необходимости корректно «стыковать» разрабатываемую архитектуру с типовой конфигурацией. Это позволяет не ограничено отражать и развивать отраслевую специфику в автоматизации, насколько бы значительной она не была.
1.3.2.Недостатком подхода может казаться большая трудоемкость и длительность разработки функционала «с нуля», однако это может быть скомпенсировано наличием у разработчиков значительной базы наработок, сделанных ранее по этому подходу в автоматизации УУ. Этот базис наработок представляет своего рода конструктор («лего») из которого собирается (компонуется) нужный функционал. Заново («с нуля») разрабатывается лишь новый функционал, отражающий отраслевую специфику не встречавшуюся ранее.
1.3.3.Главной проблемой этого подхода видится интеграция УУ и РУ, если она необходима. Это потребует разработки специального функционала для синхронизации и обменов данными УУ и РУ.
1.3.3.1.В некоторых случаях такая интеграция не существенна, учетные события РУ при этом создаются не зависимо («рисуются») и, по сути, интеграция не нужна. Например, внутреннее производство в многопрофильном холдинге (МХ), где все продажи и закупки («внешние») вынесены в другие бизнесы МХ и фабрика все получает от МХ и все отдает МХ.
1.3.3.2.Однако, в случае необходимости «плотной» «онлайн» интеграции УУ и РУ, использование этого подхода в автоматизации управления предприятием затруднительно.
1.4.Разрабатывается отдельная линейка объектов для автоматизации УУ, функционал УУ представляет дополнительный модуль к типовому решению, используемому для РУ, типовые объекты конфигурации не модифицируются
1.4.1.Этот подход видится как наиболее оптимальный для долгосрочного решения проблем автоматизации управления предприятием с существенной отраслевой спецификой. Фактически в этом подходе в одной БД присутствуют две относительно независимые конфигурации: типовая для целей РУ и управленческая - «самодостаточная» полнофункциональная система объектов (отдельная линейка) для автоматизации УУ.
1.4.1.1.При этом функционал РУ «не знает» об объектах для автоматизации УУ, а объекты УУ, напротив, могут и часто в целях интеграции даже «должны» знать о соответствующих объектах РУ.
1.4.1.2.Интересно, что в этом подходе, при необходимости, БД путем прямой загрузки типовой конфигурации, может быть «усечена» чисто до данных РУ (данные и функционал УУ при этом «исчезают»), это свойство может быть использовано для целей экономической безопасности (например, при передаче БД в аудит РУ).
1.4.2.Преимуществом этого подхода, как и при написании конфигурации «с нуля» (п.1.3.1.), является его «отвязка» от типовой конфигурации, что позволяет «свободно» автоматизировать отраслевую специфику, насколько бы значительной она не была.
1.4.3.Недостаток подхода связанный с большой трудоемкостью разработки, как и при написании «с нуля» (п.1.3.2.), может быть скомпенсирован наличием у разработчиков наработок, сделанных по этому подходу ранее.
1.4.4.Большим преимуществом данного подхода в части интеграции с РУ - является возможность иметь прямые ссылки на типовые объекты РУ в объектах линейки УУ, что позволяет строить специальные сервисы соответствия данных УУ и РУ (в АУБ это т.н. механизм связей).
1.4.4.1.Это кардинально улучшает качество комплексной автоматизации учета (РУ и УУ) в сравнении с "самопиской" (п.1.3.), при необходимости значительной и оперативной интеграции УУ и РУ.
1.4.4.2.Подход позволяет строить сложные механизмы интеграции УУ и РУ, учитывающие потребности в налоговой оптимизации, когда реальные учетные события меняют свою интерпретацию для оформления деятельности в РУ.
1.4.5.Именно этот подход рекомендуется использовать в концепции АУБ для комплексной автоматизации МХ.
2.Концепция автоматизации в системе АУБ
2.1.Подход к разработке функционала УУ
2.1.1.Разработка функционала УУ в АУБ делается на отдельной линейке объектов, функционал УУ представляет дополнительный модуль к типовому решению, используемому для РУ, типовые объекты конфигурации не модифицируются.
2.1.2.Ряд основных справочников РУ, которые присутствуют во всех типовых решениях 1С, являются общими аналитиками для УУ в АУБ и РУ в типовой конфигурации, при этом метаданные справочников не изменяются. Это рекомендуется делать для более эффективной интеграции УУ и РУ. В сделанных по этому подходу наработках это справочники: Контрагенты, Валюты, Банковские счета, Физические лица.
2.2.Интеграция УУ и РУ в АУБ
2.2.1.Интеграция УУ и РУ в АУБ направлена на оперативное и согласованное отражение, прежде всего, «внешних» учетных событий: продажи и закупки, поступление и выплаты денежных средств (ДС) по банку. Эти события («внешние») отражаются в РУ и УУ, однако в результате налоговой оптимизации могут менять свою интерпретацию.
2.2.2.Документы УУ в АУБ отражающие события продажи и закупки, поступление и выплаты ДС содержат в себе не только все нужные для УУ управленческие аналитики, но и все ссылки на объекты РУ из типовой конфигурации, достаточные для создания, при необходимости, соответствующего документа в РУ. Документ АУБ «знает» помимо данных УУ и все необходимые данные РУ, включая и ссылку на сам документ РУ - свой «образ» в РУ, если он создан.
2.2.3.Что бы избежать «двойного» ручного ввода документов отражающих «внешние» события УУ и РУ, в АУБ автоматизирован процесс заполнения данных РУ в документах УУ АУБ, и само создание соответствующих «образов» УУ и РУ. В сделанных по этому подходу наработках:
- документы, отражающие движения материально-технических ресурсов (МТР), делаются и заполняются сначала в УУ, потом из них создаются «образы» в РУ;
- при отражении движения ДС (по банку), принят обратный порядок, движения ДС сначала импортируются в РУ стандартными средствами (клиент банк), корректируются и проводятся в РУ. Потом средствами АУБ из них делаются в УУ «заготовки» соответствующих документов движения ДС в УУ, с заполненными данными РУ и частично или полностью заполненными аналитиками УУ, документы проверяются, корректируются в части УУ и проводятся в УУ.
2.2.4.Для автоматизации заполнения в документах УУ, данных УУ и РУ достаточных для создания «образа», в наработках реализован специальный механизм связей аналитик УУ и РУ. Для каждой области учета, где необходимо такое сопоставление, есть соответствующие оборотные регистры (например, АУБ Связь аналитик ДДС) в ресурсах которых присутствует, помимо предметных показателей, еще «Частота», отражающая количество позиций реализованной связи. При заполнении в документах УУ, данных УУ и РУ, при неоднозначности вариантов заполнения, «Частота» играет роль приоритета в предлагаемых комбинациях. Сервис связей позволяет эффективно заполнять в документах УУ, данных УУ и РУ. Система как бы «самообучается» и в результате наработки связей трудоемкость заполнения аналитик РУ в объектах УУ не значительна (аналитики РУ подставляются автоматически почти всегда и пользователи даже забывают, откуда система их «знает»). Эта система хорошо отработана и прошла длительную практику.
2.3.Уровни автоматизации и стратегические центры ответственности (СЦО) в АУБ
2.3.1.Основным принципом концепции АУБ необходимым для автоматизации УУ многопрофильного холдинга (МХ), является разделения УУ на три уровня: Технический (или оперативный) уровень (ТехУр), Экономический уровень (ЭкУр) и Стратегический уровень (СтрУр). Каждый уровень является источником для принятия управленческих решений в своей области УУ, как правило, с ними работают разные специалисты. Уровни в АУБ относительно не зависимые, и вообще говоря, могут вестись не зависимо, но правильно когда фактические данные поступают «снизу в верх» - из ТехУр в ЭкУр, из ЭкУр в СтрУр. Плановые данные, могут быть получены как "сверху вниз" так и "снизу вверх" (встречное планирование).
2.3.2.В целом МХ в АУБ рассматривается как совокупность СЦО, в каждом СЦО УУ разделяется на три уровня. Отдельные СЦО, это области бизнеса МХ значительно разделенные по региональному или отраслевому признаку. Внутри СЦО есть ЛЦО (локальные центры ответственности отражающие его внутреннюю управленческую орг.структуру), разделение же на СЦО целесообразно, когда области бизнеса разделены территориально или по отраслям на столько сильно, что оперативное управление ими не целесообразно из одного центра. Значительные отраслевые различия часто связаны с тем, что функционал оперативного учета (ТехУр) у них сложно совместим по архитектуре. Автоматизация УУ отдельных СЦО МХ происходит в отдельных автономных информационных системах, данные которых консолидируются только в части СтрУр*.
* 2.3.2.1.Допускается возможность консолидации в АУБ данных МХ и на «низких» уровнях (ТехУр), но только в рамках «узких» «замкнутых» функциональных областей ЗОМ (замкнутая область метаданных). Например, отдельных справочников (клиенты) или специализированных «узких» подсистем (идентификация сотрудников). При этом эти ЗОМ должны быть «внедрены» (без каких либо изменений) в состав функционала ТехУр всех СЦО МХ.
2.3.3.Основной задачей ТехУр является поддержка оперативного управления бизнесом. ТехУр оперирует с точными и детальными понятиями. Для управления производством он часто интегрируется или исполняет роль системы управления технологическим процессом (из практики, например, генератор рецептур смесей мороженого, управление весовой). Оперативное планирование в ТехУр делается с точностью до событий (не по периодам), а фактические события отражаются в ТехУр так, как они происходили в реальности. Именно функционал ТехУр сильно зависит от отраслевой специфики, поэтому в рамках одного СЦО сложно соединять функционал ТехУр «не совместимых» направлений деятельности в случае значительных отраслевых различий, но, как правило, это не целесообразно и из соображений оперативного управления из одного центра. Именно эффективная автоматизация ТехУр создает наиболее очевидные «выгоды» для бизнеса от УУ.
2.3.4.Экономический уровень используется для определения и планирования показателей деятельности СЦО по периодам (обычно месяц) в аналитических разрезах, укрупненных по отношению к ТехУр. На нем рассчитывается фактическая себестоимость выпускаемой продукции, определяется доходность различных сегментов деятельности СЦО, формируется управленческий баланс, определяется управленческая прибыль за отчетный период. Фактические и плановые операции (по различным сценариям планирования) на этом уровне могут отражаться в формате проводок по управленческому плану счетов (УпрПлСчетов) и/или оборотами по видам движений бюджетирования с указанием бюджетных аналитик. На этом уровне рассчитываются бюджеты всех видов с фактическими и плановыми показателями, автоматизируется система бюджетного управления.
2.3.5.Стратегический уровень необходим для решения задач консолидации показателей деятельности в МХ и бизнес планирования по инвестиционным проектам. Самым детальным аналитическим разрезом данных СтрУр являются статьи различных бюджетов. Данные бюджетов, рассчитываемые на ЭкУр, фиксируются на СтрУр в СЦО специальными документами и для консолидации в масштабах всего МХ, передаются в специальную центральную БД («корону») объединяющую данные СтрУр всех СЦО МХ. Основным инструментом бизнес планирования на СтрУр являются в бизнес калькуляторы (БК), представляющие сервисы для расчетов показателей инвестиционных проектов. Функционал БК не входит в метаданные конфигурации, представляя внешние обработки, сохраняемые в данных БД в справочнике БК. Бизнес калькулятор реализует определенную экономическую модель инвестиционного проекта и может делать различные расчеты проектов, результаты которых составят бизнес-план. Результаты расчетов проектов могут сохраняться в БД в данных СтрУр или во внешних файлах, на основании одних расчетов, путем изменения их параметров и пересчетом, могут делаться новые скорректированные расчеты. Бизнес калькуляторы, планируемые инвестиционные проекты и результаты расчетов проектов, консолидируются в МХ в центральной БД МХ, вместе с данными бюджетов фиксируемыми на СтрУр в СЦО. В процессе бизнес планирования в МХ справочник БК может нарабатываться и расширяться, образуя базис готовых экономических моделей для развития МХ. Так же в АУБ предусмотрен инструмент передачи результатов расчетов бизнес калькулятора («сверху вниз») в ЭкУр и добавки их в «тело» определенного сценария планирования, это нужно для более полного и интегрированного с текущей деятельностью СЦО анализа плановых показателей бюджетов, в случае расширения бизнеса СЦО новым инвестиционным проектом.
2.4.Порядок бизнес планирования в АУБ
2.4.1.В качестве рекомендации в АУБ может быть предложен определенный регламент бизнес планирования по инвестиционным проектам (ИП) в МХ. Понятно, что ИП нельзя начинать без проработанного бизнес-плана. В АУБ бизнес-план формируется из различных вариантов расчетов ИП, производимых с использованием специальных сервисов - бизнес калькуляторов (БК).
2.4.2.В основе ИП должна быть некая бизнес-идея, которая содержит смысл, определяющий некоторую экономическую модель развития бизнеса, которая ляжет в основу бизнес-плана ИП. В качестве носителя («движителя») этой идеи обычно выступает определенное лицо, внешнее или внутреннее по отношению к МХ, которое является инициатором инвестиционного проекта (ИИП). Первым шагом следует проверка ИИП на «добросовестность» соответствующими службами МХ. Результатом проверки должно быть определено, что это не профессиональная «разводка на деньги», а вот напротив кажущееся «безумие» идеи не должно быть препятствием на этом шаге, т.к. с порога отбрасываемые «бредовые» идеи иногда оказываются очень плодотворными.
2.4.3.Следующим шагом предлагается предварительная презентация и оценка предметными (отраслевыми) специалистами, которые способны оценить есть или нет в предложениях ИИП плодотворная бизнес-идея. Это далеко не окончательное решение и поэтому может быть не очень строгим по отношению к ИИП. Для оценки достаточно утверждения, что «возможно что-то есть».
2.4.4.В дальнейшем ИИП должен быть сведен с разработчиком БК для совместной работы над созданием БК в АУБ. Нужно отметить, что разрабатывать БК вряд ли сможет «чистый программист (кодер)», это все же должен быть специалист владеющий, хотя бы на базовом уровне экономическими и предметными знаниями, или это может быть группа разработки. В результате их совместной работы должна произойти «передача смысла», в результате которого бизнес-идея продвигаемая ИИП воплотится в реализованную в функционале БК экономическую модель развития бизнеса. В итоге ИИП освоив функционал БК должен признать, что это как раз то, что он предлагает. Понятно, что это будет, скорее всего, сложный инструмент с многочисленными параметрами расчета. Используя его можно делать неограниченное количество вариантов расчета по реализованной модели. Если бизнес-идея реализованная в БК плодотворная, то уже на этом этапе есть некоторый положительный результат, в случае даже если ИП и не будет запущен, БК может «подождать своего часа». С другой стороны - сам факт, что удалось сделать БК, косвенно подтверждает наличие смысла в идее ИИП, т.к. хаос запрограммировать нельзя.
2.4.5.В дальнейшем создается более представительная группа специалистов, целью которой является подготовка с использованием созданного БК расчетов ИП, результаты которых войдут в окончательный вариант (или нескольких на выбор) бизнес-плана. Состав группы должен содержать ИИП, разработчика БК, предметных отраслевых специалистов, сотрудников финансово-экономического отдела (ФЭО). В процессе их работы возможна отправка БК на доработку, в случае выявления каких либо упущений в реализованной им экономической модели развития бизнеса. В случае отправки БК на доработку процесс бизнес планирования возвращается на п.2.4.4.
2.4.6.Полученный окончательный вариант (или нескольких на выбор) бизнес-плана должен быть презентован инвесторам (учредителям) МХ в составе совещания включающего ИИП, предметных специалистов, сотрудников ФЭО и их руководителей. В результате этого совещания/совещаний бизнес-план утверждается и запускается в работу, откладывается на будущее или отклоняется как нецелесообразный.
2.5.Номенклатура в АУБ
2.5.1.В концепции и наработках АУБ реализован определенный подход к отражению материально-технических ресурсов (МТР) в УУ и РУ. Этот подход сформировался в результате опыта и анализа различных проектов автоматизации УУ. В результате в концепции АУБ определена необходимость использования параллельно трех относительно независимых, но связанных между собой, номенклатур: Бухгалтерская номенклатура; Техническая номенклатура; Экономическая номенклатура.
2.5.2.Бухгалтерская номенклатура
Бухгалтерская номенклатура (БухНом), это номенклатура типового решения, используемого для РУ, без какой либо модификации. В типовых решениях она представлена типовым справочником «Номенклатура» и в ряде типовых конфигураций еще дополнительным (подчиненным) справочником «Характеристики номенклатуры» - позиционируемым в типовой архитектуре как «управленческое» расширение номенклатуры. Для отражения МТР УУ в АУБ она не используется, за исключением «представительских» целей в печатных формах «внешних» учетных событий. Хотя для целей интеграции УУ и РУ в АУБ, в документах УУ отражающих движения МТР - БухНом указывается (п.2.2.2.) и сопоставляется в механизме связей (п.2.2.4.) своему управленческому аналогу - Технической номенклатуре, это нужно для создания, при необходимости, соответствующего документа в РУ.
2.5.3.Техническая номенклатура
Техническая номенклатура (ТехНом), это детальная (точная, инженерная, технологическая) управленческая номенклатура, используемая в ТехУр УУ АУБ для оперативного управления бизнесом. ТехНом используется для детального (точного) УУ МТР в АУБ, она отражается в фактических событиях продаж, производства, закупок, в оперативном планировании и обязательствах по сделкам в УУ. В ТехНом учитываются точные остатки МТР в УУ, она отражается в технологических спецификациях УУ АУБ. Для ТехНом реализован в УУ АУБ учет прайсовых цен продаж и закупок по типам цен и контрагентам. Для ТехНом реализован механизм учетных цен («детальных»), используемый для оценки стоимости МТР в УУ АУБ, и расчет «точной» «сырьевой» нормативной себестоимости продукции и ПФ по спецификациям и учетным ценам ТехНом сырья. Периодичность регистра сведений «АУБ Цены технической номенклатуры» учета цен на ТехНом - день (цена устанавливается не чаще чем один раз в день).
2.5.4.Экономическая номенклатура
В концепции АУБ, так же определена необходимость ведения специальной экономической номенклатуры, представленной в наработках справочником «Объекты затрат» (ОЗТ). ОЗТ - эта агрегированная (укрупненная) номенклатура, используемая в АУБ для экономического планирования по периодам (например, шаг месяц, горизонт год). Именно по ОЗТ рассчитывается фактическая себестоимость за период и формируется плановая калькуляция на ЭкУр. Она является самым детальным аналитическим разрезом для отражения МТР на ЭкУр УУ в АУБ. ОЗТ используется как субконто по УпрПлСчетов для учета МТР. Справочник ОЗТ формируют и работают с ним, как правило, сотрудники ФЭО.
2.5.4.1.Уровень детализации элементов ОЗТ не однороден и может изменяться от точности близкой к ТехНом, до агрегации характерной для статьи бюджета.
2.5.4.2.ОЗТ отражающее выпускаемую продукцию, как правило, мало агрегировано и по детальности близка к ТехНом, но при этом обычно используется другая («обобщающая») единица измерения (ЕдИзм). Например, из практики, для продукции ЖБИ ЕдИзм ТехНом это штуки, а для ОЗТ это кубы, для продукции мороженого ЕдИзм ТехНом это также штуки, а ОЗТ измеряется в тоннах. Можно сказать, что для ОЗТ, отражающего выпускаемую продукцию, ЕдИзм обычно соответствует ЕдИзм основного полуфабриката этого вида продукции.
2.5.4.3.Основное сырье производства в справочнике ОЗТ более агрегировано, чем продукция, но детализировано, как минимум, по группам сырья.
2.5.4.4.Что касается товаров, материалов, запчастей и прочих материальных ценностей то уровень агрегации в элементах ОЗТ соответствует уровню, используемому в статьях бюджетов.
2.5.4.5.Для правильной работы функционала АУБ элемент справочника ОЗТ должен настраиваться в зависимости от заложенной в нем агрегации и роли в учете. По элементу ОЗТ опционально указывается признаки: наличие количественного учета; наличие учетной цены; наличие нормативной калькуляции (значит, что элемент ОЗТ продукция или полуфабрикат).
2.5.5.Управление справочниками номенклатуры
Использования в АУБ параллельно трех номенклатур имеет как функциональные, так и организационные причины. В зависимости от различной роли в учете, более правильно и просто реализовывать функционал УУ, имея для этого разные справочники номенклатуры. Но главная причина все же организационная - у каждой номенклатуры должен быть свой «хозяин».
2.5.5.1.Например, БухНом и ТехНом по детализации близки. Но что делать, если главный бухгалтер хочет «размножить» номенклатуру, так как одна и та же позиция номенклатуры, в одной организации - выпускаемая продукция, в другой - товар, а для третьей - сырье, используемое для выпуска другой продукции, и он хочет видеть их в разных номенклатурных группах.
2.5.5.2.Для запчастей и материалов инженеру критически важно точное знание наличия соответствующей детали, а для бухгалтера, например, имеет значение - как называется эта позиция в счет фактуре полученной от поставщика, а одна и та же позиция материала или запчасти, как правило, отличается по названию в сопроводительных документах разных поставщиков.
2.5.5.3.Это частные примеры, а проблема в том, что у бухгалтеров и «технарей» разные приоритеты и требования к справочнику номенклатуры. Бухгалтер сосредоточен на оформлении деятельности, создании отчетности перед госорганами и налоговой оптимизации. А у технического специалиста на первом месте стоят задачи технологического и инженерного характера. В результате - не получается соединить в одном справочнике для нормальной работы номенклатуру для технических целей, с одной стороны (номенклатуру «технарей», инженеров, технологов) и номенклатуру, как ее хотят видеть бухгалтера, с другой. При этом, используемый в типовых конфигурациях, дополнительный подчиненный справочник «характеристики номенклатуры», этой проблемы не решает.
2.5.5.4.Ну а для экономистов, которые ведут укрупненное планирование, расчет итоговых показателей деятельности предприятия за отчетный период и занимаются системой бюджетного управления, вообще отдельное «видение» номенклатуры и требования к ней в части детализации, единиц измерения и самого наличия количественного учета, при отражении различных видов МТР.
2.6.Аналитики и функционал экономического уровня в АУБ
2.6.1.Как уже говорилось ранее (п.2.3.4.) ЭкУр используется для планирования и учета фактических результатов деятельности СЦО по периодам (обычно месяц) в укрупненных аналитических разрезах. Нужно отметить, что функционал ЭкУр, в отличии от ТехУр, слабо зависит от отраслевой специфики. Поэтому созданный ранее в наработках АУБ функционал может быть практически готовой базой в новых проектах автоматизации УУ в части ЭкУр. Кратко опишем реализованный в наработках АУБ функционал ЭкУр.
2.6.2.Все движения ЭкУр (проводки по УпрПлСчетов и/или обороты по видам движений бюджетирования) отражаются по определенным сценариям. Фактические данные учитываются в регистрах аналогично плановым, но по предопределенному сценарию «Факт основной». Для плановых сценариев определяется периодичность (шаг, интервал движений) и горизонт планирования.
2.6.3.Главным отличием подхода АУБ от функционала бюджетирования типовых решений - это то, что фактические данные не импортируются из РУ в результате работы специального «сложно настраиваемого» функционала импорта, т.к. они «всегда на месте» и «поднимаются» на ЭкУр из ТехУр «онлайн», изначально являясь данными УУ, а не РУ. Данные поступают непосредственно из первичных документов УУ, отражающих реальные учетные события.
2.6.4.Функционал передачи («подъема») фактических данных из ТехУр в ЭкУр похож на используемый при интеграции с РУ (п.2.2.3., п.2.2.4.). После инициализации учета в ЭкУр АУБ (возможность опциональна) в документах ТехУр появляется необходимость (и функционал) указывать все нужные для ЭкУр управленческие аналитики.
2.6.5.Для автоматизации заполнения в документах ТехУр аналитик ЭкУр, в наработках реализован специальный механизм связей ТехУр и ЭкУр, который существенно облегчает эту задачу. Система «самообучается» и после наработки связей (правильных) трудоемкость заполнения аналитик ЭкУр в документах ТехУр не значительна.
2.6.6.Так же для ввода любой фактической операции можно использовать универсальный документ ЭкУр УУ «АУБ Операция Факт», который делает проводки по УпрПлСчетов и/или обороты по видам движений бюджетирования отражаемые по заданному сценарию (документ используется для ввода «одномоментных» операций, а не «на горизонт в целом»). Это управленческий аналог типового документа РУ «Операция (бухгалтерский и налоговый учет)».
2.6.7.Ранее говорилось, что движения в ЭкУр отражаются проводками по УпрПлСчетов и/или оборотами по видам движений бюджетирования. Справочник АУБ «Виды движений бюджетирования» близок по смыслу утвержденному перечню проводок УУ по УпрПлСчетов. Вид движения однозначно определяет проводку (Счет Дт и Кт), но вообще говоря, разные виды движений могут иметь и одинаковую проводку, хотя такая практика не желательна. В АУБ учет движений ЭкУр можно вести (параллельно с проводками или без них) оборотами по видам движений в разрезе сценариев, видов движений и всех необходимых аналитик ЭкУр. Основной оборотный регистр ЭкУр для этого - «АУБ Движения», с измерениями: «Сценарий», «Вид движения», тремя фиксированными аналитиками («ОЗТ, СД, ЛЦО») и четырьмя аналитиками переменного типа («Аналитика1,2,3,4»), с тремя ресурсами «Количество, Сумма, Сумма вал», реквизитами «УИД, Содержание». Данные записи регистра однозначно, при необходимости, определяют проводку по УпрПлСчетов со всеми аналитиками (субконто), ресурсами и реквизитами. Особенностью этой схемы движений является то, что в одном движении один и тот же вид аналитики может использоваться только один раз. Поэтому для операций переноса или производственного преобразования используется специальные транзитные счета УпрПлСчетов, при этом операция образует пару движений. Это ограничение может быть использовано и с «пользой» - для исключения «экономически бессодержательных» оборотов по счетам УпрПлСчетов, например, складские перемещения, тогда используется прямая проводка и ее сторно по новой измененной аналитике.
2.6.8.При настройке состава движений по сценарию (проводки и/или обороты) нужно понимать, что делать проводки по какому либо сценарию правильно, если на нем развернут достаточно «полный» учет. Такой учет следует ожидать для сценария учета фактических данных, но даже на нем, в начале «раскрутки» УУ ЭкУр проводки делать рано. Значительное время можно вести УУ ЭкУр по сценарию, используя только обороты по видам движений, без ущерба для получаемой управленческой информации. Для некоторых сценариев, отражающих лишь определенную предметную область (часть деятельности) или функциональную область (например, только данные БДДС) учет проводок вообще не нужен.
2.6.9.Возможность, как именно отражать движения ЭкУр, гибко настраивается в АУБ для каждого сценария отдельно. Регламентный документ настройки сценария в части способа отражения движений (проводки и/или обороты) и актуальной даты ввода начальных остатков по сценарию называется «АУБ Настройка сценария».
2.6.10.Многие задачи ЭкУр, включая, например, расчет фактической себестоимости выпускаемой продукции, определения доходности различных сегментов деятельности СЦО, можно решать и без проводок по УпрПлСчетов. Но нельзя будет без проводок сформировать, например, управленческий баланс СЦО.
2.6.11.Общие аналитики для УУ и РУ
Перечислим аналитические разрезы ЭкУр, при этом часть этих аналитик являются общими для УУ в АУБ и РУ в типовой конфигурации (для лучшего сопоставления показателей УУ и РУ). Общие аналитические разрезы УУ ЭкУр и РУ это: Валюты, Банковские счета, Контрагенты, Физические лица. Эти типовые справочники РУ используются в УУ АУБ, без какой либо модификации метаданных.
2.6.12.Аналитики АУБ для УУ
Остальные («специфические» для АУБ) аналитики ЭкУр используются только в УУ, коротко определим их смысл.
2.6.12.1.Объекты затрат
Объекты затрат (ОЗТ) - это (говорилось ранее п. 2.5.4.) агрегированная (укрупненная) «экономическая» номенклатура, используемая для отражения движений материально-технических ресурсов (МТР) на ЭкУр. Для операций (учетных событий) с МТР она отвечает на вопрос - «Что это?».
2.6.12.1.1.В УУ ОЗТ может иметь учетные цены фактической (ФактУЦ) и плановой (ПланУЦ) себестоимости, в чем-то это аналог учетных цен на ТехНом (по типам) в ТехУр. Периодичность регистров сведений учета ФактУЦ и ПланУЦ месяц (цена устанавливается не чаще чем один раз в месяц).
2.6.12.1.2.Возможность ОЗТ иметь учетные цены и количественный учет зависит от заложенного в этот элемент уровня детализации МТР и настраивается (обязательно) установкой признаков: наличие количественного учета; наличие учетной цены; наличие нормативной калькуляции (ОЗТ производится).
2.6.12.1.3.Цены ФактУЦ и ПланУЦ на ОЗТ зависят от значений других аналитических разрезов характеризующих направление деятельности и территорию использования МТР отражаемого этим ОЗТ.
2.6.12.1.4.ФактУЦ ОЗТ определяется по итогам деятельности за месяц, при расчете фактической себестоимости выпускаемой продукции, документом «АУБ Закрытие месяца» и по умолчанию устанавливается на следующий период. Установленное в результате расчета значение ФактУЦ ОЗТ может быть скорректировано вручную, если в результате расчета получилась «плохая» ФактУЦ. Такое возможно, например, когда в производственном участке были «форс-мажорные» обстоятельства и рассчитанная цена фактической себестоимости только «дезинформирует», при принятии управленческих решений по данным ЭкУр УУ.
2.6.12.1.5.Для ОЗТ, производимого в СЦО, устанавливается плановая калькуляция (справочник «АУБ Калькуляции для ОЗТ»). В чем-то это аналог ЭкУр справочника «АУБ Спецификации» ТехУр, но если спецификации решают «точные» технологические задачи, то калькуляция определяет плановый состав и стоимость поглощенных на производство ОЗТ ресурсов, с учетом направлений деятельности и территориального фактора. В состав («на вход») калькуляции могут входить ОЗТ «статейного» уровня агрегации, определяя лишь поглощенную стоимость по определенной статье затрат.
2.6.12.1.6.ПланУЦ ОЗТ, производимого в СЦО, рассчитывается на основании его калькуляции документом «АУБ Закрытие месяца» и устанавливается на следующий период, но может быть откорректирована вручную, если в результате расчета получилась «плохая» ПланУЦ в связи с, например, недоработанной калькуляцией для ОЗТ.
2.6.12.1.7.Если ОЗТ не производится, в определенном направлении деятельности и территории, но детализация ОЗТ допускает наличие учетной цены, цена ФактУЦ может быть выбрана вручную и установлена документом «АУБ Закрытие месяца». Это может иметь смысл, например, когда в управлении СЦО принята учетная модель УУ, использующая трансфертные цены и передачи внутри СЦО. В этом случае трансфертная цена продажи для бизнеса «продавца» равна ФактУЦ, которая установлена у бизнеса «получателя» как учетная для ОЗТ (внутри СЦО по деятельности и территории «получателя»).
2.6.12.1.8.Ранее говорилось, что ОЗТ может быть «статейного» уровня агрегации и тогда для нее вообще не может быть ФактУЦ, и вообще для ОЗТ, которые не производятся в СЦО, устанавливать ФактУЦ не обязательно. Оценка стоимости оборотных средств по МТР производится по принципу, если есть по ОЗТ ФактУЦ, то оценка берется на основании ФактУЦ, если нет (например, ОЗТ «статейное»), то оценка делается на основании данных ТехУр по учетной цене ТехНом и ее количества (п.2.5.3.) на ТехУр . Это возможно, так как для ЭкУр есть регистр учета остатков сопоставляющий для МТР данные ТехУр и ЭкУр («АУБ Запасы аналитика бюдж»). После инициализации учета в ЭкУр АУБ все данные МТР ТехУр привязываются к аналитикам ЭкУр документом «АУБ Ввод начальных остатков» и это соответствие всегда поддерживается, любые данные МТР ТехУр всегда «представлены» в определенных разрезах ЭкУр. Исключение составляет Брак, он отражается только на ТехУр и не учитывается на ЭкУр, не попадая в оценку стоимости МТР.
2.6.12.1.9.Для ЭкУр СЦО не имеющих в своем составе производственных подразделений, например, чисто торговые предприятия, все ОЗТ могут быть «статейного» характера, при этом оценка стоимости оборотных средств, для МТР будет делаться только по данным ТехУр на основании учетных цен ТехНом и ее количества на ТехУр. При изменении учетной цены ТехНом (периодичность регистра ТехУр «АУБ Цены технической номенклатуры» день) текущая переоценка на ЭкУр не делается, общий результат переоценок за период рассчитывается и проводится документом «АУБ Закрытие месяца».
2.6.12.1.10.ФИФО в АУБ не используется, стоимости МТР оценивается по учетным ценам, если они меняются, то это вызывает соответствующую переоценку стоимости МТР, но переоценка делается не в текущем режиме, это вызвало бы неустойчивость из-за движений МТР введенных задним числом, а по итогам работы за месяц документом «АУБ Закрытие месяца». Суммы переоценок в соответствующих аналитических разрезах учета МТР проводятся документом «АУБ Закрытие месяца» итогом за период со счетов учета МТР на счет 16.02 (Отклонения по переоценке ОЗТ). Так же этот документ итогом за период в аналитических разрезах учета МТР проводит и виды отклонений по субсчетам счета 16.01 (Отклонения в производстве) и 16.03 (Отклонения по поступлению ОЗТ).
2.6.12.2.Локальные центры ответственности
Локальные центры ответственности (ЛЦО) - это справочник (иерархия элементов) который определяет управленческую организационную структуру СЦО. Слово «локальный» в составе названия указывает на то, что это «внутренняя» оргструктура СЦО (стратегического центра ответственности МХ). Разные СЦО МХ имеют каждый «свой» состав справочника ЛЦО. Для учетных событий УУ аналитика ЛЦО отвечает на вопрос - «Кто отвечает за это действие (чья зона ответственности)?».
2.6.12.2.1.Для каждого ЛЦО должно быть определено ответственное физическое лицо.
2.6.12.2.2.В подсистеме учета управленческой зарплаты АУБ ЛЦО используется обязательно, даже если учет на ЭкУр в текущий период не инициализирован и учет в СЦО ведется только на ТехУр.
2.6.12.2.3.В учете ЭкУр по счетам УпрПлСчетов ЛЦО используется только как оборотное субконто (без учета остатка на счете) разделяя только обороты операций по счетам («события»), исключением являются счета учета отклонений (субсчета счета 16 «Отклонения»). В счетах учета отклонений субконто ЛЦО не оборотное (есть учет остатков).
2.6.12.3.Сегменты деятельности
Сегменты деятельности (СД) - это отдельные направления деятельности («бизнесы») внутри СЦО, с обособленным учетом доходов и расходов. Для учетных событий аналитика СД отвечает на вопрос - «Для чего (для какой деятельности) это?». Разные СЦО МХ имеют каждый «свой» состав справочника СД. Структура справочника СД - это иерархия элементов.
2.6.12.3.1.Только по аналитике СД, можно учитывать «отдельный» маржинальный доход направления деятельности СЦО на ЭкУр в АУБ.
2.6.12.3.2.СД является разделителем при расчете себестоимости и установке и учетных цен ФактУЦ и ПланУЦ на ОЗТ (совместно с аналитикой учета территориального фактора - ЛМЗ) на ЭкУр.
2.6.12.4.Локальные места затрат
Локальные места затрат (ЛМЗ) - это справочник (иерархия элементов) который определяет разделение деятельности СЦО по территориальному признаку. Слово «локальный» в составе названия указывает на то, что это «внутренняя» для СЦО территориальная структура. Разные СЦО МХ имеют каждый «свой» состав справочника ЛМЗ.
2.6.12.4.1.ЛМЗ используется в ЭкУр для учета разделения основных средств, оборотных МТР, расходов и затрат по территориям, отвечая для них на вопрос - «Где это?».
2.6.12.4.2.Влияние на бизнес различий территориального фактора для разных элементов ЛМЗ должно быть значимым для бизнеса, т.е. не правильно создавать отдельные ЛМЗ, как разные склады на одной территории.
2.6.12.4.3.ЛМЗ является разделителем при расчете себестоимости и установке учетных цен на ЭкУр по ОЗТ: ФактУЦ, ПланУЦ (совместно с аналитикой направлений деятельности - СД).
2.6.12.5.Потоки затрат
Потоки затрат (ПЗТ) - это справочник (иерархия элементов) который определяет крупные ОС или группы ОС, другие амортизируемые агрегированные активы, резервы под условные активы и условные обязательства, используемые в УУ ЭкУр АУБ. Для объектов учета ПЗТ отвечает на вопрос - «Что это?».
2.6.12.5.1.Отметим, что для учета ОС на ЭкУр отдельные элементы ПЗТ правильно использовать только в случае крупных, определяющих для бизнеса ОС, например, здания, технологические линии и т.п., в основном элементами ПЗТ целесообразно отражать группы ОС имеющие однородный состав и назначение. Детальный управленческий учет ОС ведется в АУБ на ТехУр в подсистеме «Управление имуществом» в составе «Объектов имущества».
2.6.12.5.2.Каждый ПЗТ создает в учете некоторый «потоков расходов». В реквизите ПЗТ задается корреспондирующее ОЗТ («статейного» уровня агрегации), по которому учитываются образуемые ПЗТ затраты.
2.6.12.5.3.Основным «содержанием» ПЗТ для функционала АУБ, это возможность гибкой настройки (нормирования) «потока расходов» создаваемого в учетном процессе этим ПЗТ. Каждый ПЗТ имеет свои элементы нормировки (подчиненный для ПЗТ справочник «Нормировка ПЗТ»). Каждый элемент нормировки определяет некоторый алгоритм для расчета нормативного списания затрат и/или отклонений (при нарушении граничных значений стоимости «числящейся» на ПЗТ).
2.6.12.5.4.Для каждого элемента нормировки ПЗТ задается «Вид нормы ПЗТ»: «Амортизация линейный способ» / «Амортизация уменьшаемый остаток» / «Нормативное списание на день» / «Нормативное списание на месяц» / «Минимальный остаток на ПЗТ» / «Максимальный остаток на ПЗТ» (реализовано в наработках). Дополнительно для каждого элемента нормировки ПЗТ в регистре сведений «Значения норм ПЗТ» хранится значение нормы, указывается счета учета, счет списания, СД, ЛМЗ. Для вариантов вида «Нормативное списание» значение нормы может указываться либо по сумме, либо в количестве некоторого ОЗТ («образца»), тогда сумма нормы равна стоимости заданного в значении нормы количества ОЗТ по его учетной цене (ФактУЦ для СД и ЛМЗ элемента нормировки). Для вида норм «остаток на ПЗТ» элемент нормирования «контролирует» границы стоимости накопленной на ПЗТ, и если они нарушены, то по итогам периода документом «АУБ Закрытие месяца» формируются движения отклонений, например, в Дт счета 16.21 «Отклонения от норм по ПЗТ».
2.6.12.5.5.Нужно отметить, что в ЭкУр УУ, для «правильности» определения текущих результатов деятельности СЦО, важно широкое применение различных резервов (в АУБ использования ПЗТ «резервного типа»), например, под плановые капитальные ремонты технологических линий, их модернизацию, реструктуризацию производства. Если этого не делать, то показатели деятельности СЦО полученные УУ, существенно искажаются. Они получаются завышенными в периоды между этими событиями (капремонт и т.д.), а в периоды включившие их сильно заниженными.
2.6.12.5.6.Использование в АУБ ПЗТ «резервного типа» можно рассматривать не только как средство обеспечения «правильности» текущих результатов («сглаживания» расходов), но и как средство контроля и управления резервируемыми расходами, задавая для ПЗТ как элементы нормировки определяющие затраты, так и элементы определяющие граничные значения, при выходе за которые автоматизировано возникнут «сигнализирующие отклонения». Так, например, возможен подход, при котором ПЗТ «резервного типа» создаются по некоторым видам «сезонных» налогов. При этом «топы» «договариваются» с финансовой службой об их величине, например, на год и ПЗТ соответственно нормируется. Текущие результаты деятельности СЦО определяются по нормативным значениям налоговых расходов, а по итогам года делается «разбор полетов» и, при наличии значительных отклонений, принимаются управленческие решения, например, меняется «схема оформления» бизнеса.
2.6.12.6.Финансовые потоки
Финансовые потоки (ФПТ) - это справочник (иерархия элементов) который определяет укрупненную аналитику учета взаиморасчетов в ЭкУр УУ. ФПТ отражает крупные группы движений денежных средств (ДС), дебиторской задолженности (ДЗ) и кредиторской задолженности (КЗ) внутри СЦО. Для движений денежных средств и задолженности ФПТ отвечает на вопрос - «Оплата за что это?». Разные СЦО МХ имеют каждый «свой» состав справочника ФПТ.
2.6.12.6.1.В учете ЭкУр по счетам УпрПлСчетов ФПТ используется как субконто для счетов учета взаиморасчетов. В счетах учета, где используется ФПТ, используется и субконто «Контрагенты», которое детализирует ФПТ. Классификация ФПТ может использовать несколько различных признаков, при этом состав справочника ФПТ может быть результатом частичного «перемножения» этих признаков.
2.6.12.6.2.Признак условий по оплате. Например, может быть целесообразным разделять на различные ФПТ взаиморасчеты, где предусмотрены существенно отличающиеся условия оплаты: предоплата, краткая отсрочка платежа, длительная отсрочка. Это позволит эффективней контролировать исполнение обязательств погашения по ДЗ и КЗ. Например, определенный вид продукции для некоторой группы покупателей СЦО отгружается только по предоплате и отражается в рамках ФПТ (созданного с учетом этого признака), даже при предварительном анализе, появление в учете на этом ФПТ ДЗ, говорит о нарушении условий оплаты.
2.6.12.6.3.Признак оформления движения ДС. Может иметь смысл разделять на отдельные ФПТ взаиморасчеты в УУ оформленные по разным организациям (юр. лицам, где они учтены в РУ) в составе СЦО, и отдельно, если они вообще не оформлены в РУ.
2.6.12.6.4.Признак направлений деятельности. В ряде случаев может быть важным видеть взаиморасчеты УУ (суммы ДЗ и КЗ) по отдельным направлениям деятельности СЦО. Это имеет смысл, например, для более точного расчета суммы инвестиций, вложенных в отдельные бизнесы СЦО и оценки их окупаемости. Кроме этого планировать и контролировать фактические движения ДС в привязке к направлениям может быть целесообразным, т.к. за ними стоят «ответственные» руководители, с которыми можно решать вопросы финансовой дисциплины.
2.6.12.6.5.Признак вида хозяйственных отношений с контрагентом. Целесообразно разделять на отдельные ФПТ взаиморасчеты продаж продукции, закупки сырья, оборудования, расходных материалов и запчастей, прочие взаиморасчеты.
2.6.12.6.6.Возможны и какие либо другие признаки, учитываемые при формировании структуры справочника ФПТ. Важно, что бы в результате была сформирована архитектура справочника, позволяющая эффективно проводить «укрупненный» анализ и управлять движением ДС, состоянием ДЗ и КЗ. Не следует сильно «размельчать» справочник ФПТ, это может вызвать сложности при разнесении движений ДС по ФПТ. При проектировании структуры справочника нужно исходить из принципа «минимальной достаточности».
2.6.13.Экономическое планирование
Как уже говорилось ранее (п.2.6.2.) плановые и фактические движения ЭкУр учитываются аналогично по различным сценариям, при этом фактические данные учитываются по предопределенному сценарию «Факт основной». Опишем настройку плановых сценариев и формирование плановых данных.
2.6.13.1.Настройка плановых сценариев
Для плановых сценариев необходимо определить периодичность (шаг) и горизонт планирования. При этом в силу методических и функциональных наработок в АУБ, при настройке плановых сценариев, рекомендуется придерживаться трех представленных вариантов настройки. Укрупненное планирование - горизонт год, шаг месяц. Уточненное планирование - горизонт квартал, шаг декада. Оперативное планирование - горизонт декада, шаг день.
2.6.13.2.Использование этих трех вариантов связано с функционалом основного универсального документа «АУБ Операция План», используемого для ввода плановых движений «по шагам на горизонт в целом» и с возможностью корректно соотносить шаги «укрупненных» сценариев к шагам более «детальных» сценариев, т.е. при этом нужна «вложенность» шагов.
2.6.13.3.Укрупненное планирование
Укрупненное планирование: горизонт планирования год, периодичность (шаг) месяц. Это основной вариант экономического планирования, на нем можно учитывать корректно все данные, включая данные по затратам.
2.6.13.3.1.Многие значимые для БДР затраты определены лишь по итогам месяца, например, планируемые расходы на зарплату, амортизация производственного оборудования, расходы по аренде. Полнота движений по сценарию важна для возможности получать прогнозные данные баланса, т.к. связана с возможностью корректно вести учет проводок в ЭкУр по счетам УпрПлСчетов. Поэтому, если перед плановым сценарием стоит задача получения прогнозного баланса, то это вариант «Укрупненное планирование».
2.6.13.3.2.Также, если необходимо данные СтрУр, полученные в результате расчета бизнес калькулятора, передать («сверху вниз») в ЭкУр, добавив их в «тело» выбранного сценария планирования (п.2.3.5.), то это целесообразно делать для варианта сценария «Укрупненное планирование».
2.6.13.4.Уточненное планирование
Уточненное планирование: горизонт планирования квартал, периодичность (шаг) декада. Этот вариант экономического планирования, в большей степени подходит для уточнения плановых движений денежных средств, как по шагам, так и по сумме.
2.6.13.4.1.Уточненные движения по затратам на этом сценарии также можно отражать, но вряд ли это имеет смысл делать уточняя их по шагам. Так как три декады образуют месяц, данные по затратам можно вводить на каждом третьем шаге, уточняя их по сумме.
2.6.13.4.2.Так как всегда три декады образуют месяц, эти уточненные плановые данные можно корректно сравнивать с данными укрупненного планирования, в настроенных бюджетных формах, на интервалах кратных месяцам, например, месяц, квартал, полугодие, год.
2.6.13.5.Сценарии оперативного планирования
Оперативное планирование: горизонт планирования декада, периодичность (шаг) день. Этот вариант может быть востребован, как возможность соотносить оперативные плановые данные ТехУр с данными ЭкУр, введенными ранее по более «укрупненным» сценариям.
2.6.13.5.1.Сначала оперативные плановые данные ТехУр переводятся в стандартный формат представления плановых данных на ЭкУр (например, автоматизированным созданием документов «АУБ Операция План» по сценарию оперативного планирования) и уже потом, средствами настроенных бюджетных форм, сравниваются с данными «укрупненных» сценариев на периодах кратных их «укрупненным» шагам (декада, месяц). При этом данные этих «укрупненных» сценариев рассматриваются как «целевые» или «лимитирующие» для сценария оперативного планирования.
2.6.13.6.Ввод плановых движений
Основным универсальным инструментом ввода плановых движений «по шагам на горизонт в целом» является документ «АУБ Операция План».
2.6.13.6.1.В строке табличной части (ТЧ) документа вводятся данные достаточные для создания всей «серии» движений по шагам в целом на горизонт по сценарию для любого из трех вариантов (Горизонт/Шаг): - Год/Месяц «Укрупненное»; - Квартал/Декада «Уточненное»; - Декада/День «Оперативное». В каждой строке предусмотрено 12 позиций для ввода плановых данных «шагов» горизонта. Этих позиций всегда достаточно для любого варианта из трех, так как в году 12 месяцев, в квартале 9 декад и в декаде от 8 до 11 дней, при этом возможные «лишние» позиции блокируются. В каждой строке задается сценарий (хотя вводить одним документом данные на несколько сценариев не рекомендуется), вид движения (при выборе вида движения определяются состав необходимых аналитик строки), и все необходимые значения аналитик ЭкУр для выбранного вида движения.
2.6.13.6.2.Для каждого шага в строке ТЧ (на каждой позиции ввода) задаются все необходимые числовые параметры движения (Количество, Цена, Сумма, Курс, Сумма вал), при этом, когда данные вводятся вручную на весь горизонт, предусмотрен широкий набор сервисов для облегчения этого ввода, и редко когда приходится вводить данные на каждые шаг отдельно. Например, сервисы для заполнения строки: распространение/распределение вводимого значения на все позиции строки, сдвиг на шаг вперед / назад, пересчет по профилю индексов (по шагам) во всех строках по отбору в ТЧ и другие. Под специфику планирования в конкретном проекте автоматизации сервисы могут расширяться и дорабатываться.
2.6.13.6.3.В результате сервисов документа «АУБ Операция План», даже ручной ввод плановых данных по сценариям значительно облегчен. Но основным принципом «заполнения» новых документов «АУБ Операция План» является использование плановых данных других горизонтов и/или сценариев, то есть «по базе». Когда создание новых плановых данных (заполнение документов «АУБ Операция План») делается на базе уже созданных ранее.
2.6.13.6.4.Для принципа заполнения «по базе» в документе «АУБ Операция План» также предусмотрен набор сервисов. Примеры, сервисов для заполнения «по базе» (группами строк из ТЧ документа): - перенос строк (копирование с добавлением их в другой документ); - сдвиг даты во всех строках на горизонт планирования в будущее; - установка нового сценария во всех строках (при смене периодичности пересчет данных); - пересчет значений во всех строках по заданному профилю индексов. Таким образом, в документе «АУБ Операция План» имеется функциональность переноса движений, содержащихся в этих документах (полностью или по отбору - группами), с пошаговой индексацией по задаваемому профилю в другой горизонт и/или сценарий.
2.6.13.6.5.Следует отметить, что при формировании плановых данных из принципа заполнения «по базе», с использованием документа «АУБ Операция План», этот документ нужно стремиться наполнять однородными данными. Не следует все данные одного горизонта собирать в один документ, так же не нужно разбивать однородные данные на разные документы.
2.6.13.6.6.Оптимальным видится подход, при котором в один документ «АУБ Операция План» заполняется данными одного функционального бюджета (это бюджет, отражающий определенную сторону деятельности предприятия), или его части, если он (функциональный бюджет) содержит несколько разнородных групп данных. Например, на каждый горизонт у каждого сценария в отельный документ вводить плановые данные одного из бюджетов: продаж, коммерческих расходов, производства, производственных расходов, закупок (снабжения), оплаты труда, административных расходов и т.д.
2.6.13.6.7.Это нужно для того, что бы введенные плановые данные было удобно подвергать выборкам и модификации, при формировании новых данных «по базе», на основании уже имеющихся. Применяя ко всей группе плановых данных один алгоритм переноса и преобразования.
2.6.13.6.8.Имеющаяся функциональность документа «АУБ Операция План» позволяет гибко и эффективно переносить имеющиеся данные (группами бюджетных движений) из горизонта в горизонт, из сценария в сценарий, при этом, если сценарии имеют разную периодичность (шаг) данные не копируются, а проецируются на горизонт сценария приемника, что позволяет эффективно создавать новые плановые данные из принципа «по базе», на основании уже имеющихся в других сценариях и/или по другим горизонтам планирования. Так же документ «АУБ Операция План» имеет сервисы облегчающие ввод плановых данных вручную.
2.6.13.6.9.Следует отметить, что документ «АУБ Операция План» - не содержит функционала создания новых плановых данных, подобного функционалу бизнес калькулятора СтрУр АУБ (п.2.3.5.), реализующего определенную экономическую модель бизнеса СЦО (инвестиционного проекта).
2.6.13.7.Импорт результатов бизнес планирования
Ранее уже говорилось (п.2.3.5.), что в АУБ предусмотрен инструмент передачи результатов расчетов бизнес калькулятора (БК) из данных СтрУр («сверху вниз») в плановые данные ЭкУр и добавки их в «тело» определенного сценария планирования. Кратко опишем состав объектов и работу этого функционала.
2.6.13.7.1.Справочник «АУБ Бизнес калькуляторы» (БК) содержит набор сервисов реализующих различные экономические модели для расчетов показателей инвестиционных проектов. БК может делать различные расчеты проектов, результаты расчетов могут сохраняться в БД или во внешних файлах, на основании одних расчетов, могут делаться новые измененные расчеты. Каждый элемент справочника БК содержит внешнюю обработку, реализующую функционал БК, табличные части (ТЧ) статей расчета и параметров БК.
2.6.13.7.2.Справочник «АУБ Инвестиционные проекты» (ИП) представляет набор направлений деятельности, планируемых или уже существующих, составляющие деятельность СЦО. В элементе вводится описание ИП, дата начала и окончания проекта, заполняется ТЧ плановых сценариев используемых для ИП с указанием периодичности и комментария описывающего, например, какие данные ИП нужно отражать по этому сценарию.
2.6.13.7.3.Справочник «АУБ Расчеты проектов» (РП) содержит результаты расчетов, сохраненные в БД, полученные на основе используемых БК. Каждый элемент РП содержит ссылки на ИП, для которого этот расчет сделан и на БК, которым он проводился. Так же РП хранит и саму внешнюю обработку БК, которой он фактически рассчитывался (на случай если ее функционал был изменен в справочнике БК), дату и результат расчета БК. Так же в РП приводятся, ТЧ статей расчета и параметров БК использованного в РП.
2.6.13.7.4.Справочник «АУБ Настройки движений проектов» (НДП) содержит настройки для переноса результатов РП в движения по сценариям ЭкУр. Каждый элемент НДП ссылается на ИП, для которого сделана настройка и ее описание. В элементе НДП задается три табличных части (ТЧ): - ТЧ «Калькуляторы», для которых может быть применена настройка; - ТЧ «Статьи расчета», задействованные в расчете; - ТЧ «Настройки движений». В каждой строке ТЧ «Настройки движений» указываются статьи расчета БК для учета количества, суммы и суммы в валюте (ресурсы оборота), и вводятся данные по виду движения, и всем необходимым значениям аналитик ЭкУр для выбранного вида движения («делается привязка оборота к аналитикам»).
2.6.13.7.5.Создание движений и добавку их в «тело» определенного сценария планирования делает документ «АУБ Движения расчетов по проектам». В документе указывается ссылка на РП, данные которого «интерпретируются» для сценариев ЭкУП, и ссылка на НДП, с использованием которой проводится «интерпретация» результата РП. Так же в документе указывается дата расчета и ссылка на ИП, по результатам расчета которого делаются движения. В документе заполняется ТЧ «Сценарии» (обычно одна строка), в строке ТЧ указываются сценарий, куда делать движения, интервал, в пределах которого они вносятся в сценарий (даты начала и конца движений по сценарию), возможно сдвиг по шагам сценария относительно дат в результате расчета.
2.6.13.7.6.В результате работы этого функционала появляется возможность посредством настраиваемой «интерпретации» данных результатов РП, сделанных имеющимися БК на СтрУр, передавать их («сверху вниз») в ЭкУр и добавлять в «тело» определенных сценариев планирования. Это необходимо для более полного и интегрированного, с планами текущей деятельности СЦО, анализа показателей бюджетов, при планировании расширить бизнес СЦО новым ИП.
2.6.14.Ввод начальных остатков по счетам
Для ввода входящих остатков по заданному сценарию предназначен документ «АУБ Ввод начальных остатков». Он вводится, если по истечении некоторого периода по сценарию решено начать в ЭкУр учет проводок по счетам УпрПлСчетов, и необходимо произвести ввод начальных остатков по этому сценарию по счетам в разрезе соответствующих аналитик (субконто).
2.6.14.1.Кроме этого по предопределенному сценарию «Факт основной» документ «АУБ Ввод начальных остатков» создается всегда, когда активирован учет ЭкУр, даже если учет «факта» делается только оборотами по видам движений. Для этого сценария («факт»), документ несет дополнительный функционал настройки начального состояния специальных регистров, необходимых, для расчета фактической себестоимости выпускаемой продукции (это верно, за исключением малореального случая, когда ТехУр и «факт» ЭкУр запускаются одновременно).
2.6.14.2.Наиболее вероятный вариант развития учета для «факта», когда сначала УУ ведется на ТехУр, и уже потом, при расширении «охвата» функциональных областей автоматизации запускается ЭкУр, сначала только оборотами по видам движений и позже, когда «охвачены» все области УУ, еще и проводками по счетам УпрПлСчетов.
2.6.14.3.Для «плана» (по плановым сценариям) документ «АУБ Ввод начальных остатков» создается, когда необходимо получение прогнозного баланса по этому сценарию, и соответственно нужно вести учет проводок по счетам УпрПлСчетов.
2.6.14.4.В документе «АУБ Ввод начальных остатков» задается сценарий и дата («Дата начала»), на которую устанавливаются начальные остатки. Кроме этого заполняются остатки по различным разделам учета в следующих табличных частях (ТЧ). ТЧ Запасы ОЗТ (остатки и стоимость запасов и затрат незавершенного производства учитываемых по ОЗТ). ТЧ Запасы ПЗТ (остатки и стоимость запасов учитываемых по ПЗТ). ТЧ Безналичные ДС (остатки безналичных денежных средств на счетах). ТЧ Наличные ДС (остатки наличных денежных средств). ТЧ Взаиморасчеты контрагенты (остатки задолженности по взаиморасчетам с контрагентами). ТЧ Взаиморасчеты подотчет (остатки задолженности по взаиморасчетам с подотчетными лицами). ТЧ Прочие взаиморасчеты ФЛ (остатки задолженности по прочим взаиморасчетам с физическими лицами). ТЧ Взаиморасчеты по зарплате (остатки задолженности по взаиморасчетам с работниками по зарплате). ТЧ Объекты имущества (на дату начала стоимость в учете и амортизация объектов имущества (ОИ) учитываемых по ПЗТ). ТЧ Затраты ПЗТ (на дату начала сумма резервируемых затрат учитываемых по ПЗТ). ТЧ Прочие остатки (на дату начала суммы остатков по счетам (Дт/Кт)).
2.6.14.5.В зависимости от выбранного сценария (плановый или фактический) функционал документа «АУБ Ввод начальных остатков» отличается. Это связано с различием функционала сервисов («помощников») для заполнения этих ТЧ. Для «факта» сервисы нацелены на заполнения ТЧ документа из данных ТехУр. Для «плана» основной источник данных для заполнения ТЧ документа это «факт». Предполагается, что когда потребовался «прогнозный баланс» по плановому сценарию, то «фактический» учет проводками уже ведется. Естественно, что для ввода начальных остатков на плановый сценарий, «факт» остатков подходит, если конечно дата начала ввода проводок по плановому сценарию не в будущем или вообще плановый сценарий содержит некоторые «виртуальные» для, например, составления бизнес-плана входящие остатки (тогда они вносятся в ТЧ документа без сервисов вручную).
2.6.14.6.Ранее говорилось (п. 2.6.9.), что для сценария настраивается способ (проводки и/или обороты) отражения движений и актуальной даты ввода начальных остатков. Отметим, что по одному сценарию могут периодически вводиться новые документы «АУБ Ввод начальных остатков», например, с целью уточнить плановые остатки по счетам. Но движения (проводки) будет из них делать только тот документ «АУБ Ввод начальных остатков», в котором дата («Дата начала»), на которую устанавливаются начальные остатки, равна настроенной по сценарию актуальной дате ввода начальных остатков (п.2.6.9.). При этом остальные документы «АУБ Ввод начальных остатков» остаются для «истории» и при проведении проводок не делают, но впоследствии они могут быть использованы для «отката» назад, восстановления и анализа «старых, бывших» остатков по УпрПлСчетов этого сценария.
2.6.14.7.По сценарию «факта» следует ожидать (вероятно), что всего будет введено два документа «АУБ Ввод начальных остатков». Так как сначала будет развита автоматизация только ТехУр в области учета МТР, с возможной параллельной автоматизацией экономического планирования по ЭкУр. После автоматизации учета МТР и Затрат, можно будет автоматизировать, например, расчет фактической себестоимости выпускаемой продукции в ЭкУр УУ, это возможно без «всей полноты охвата» областей автоматизации ЭкУр и без проводок «факта», но это потребует настройки специальных регистров, что потребует для сценария «факта» ввести первый документ «АУБ Ввод начальных остатков». УУ «факта» ЭкУр уже при этом будет вестись, но только оборотами по видам движений. Позже, когда будут автоматизированы все функциональные области УУ ЭкУр АУБ, можно «включать» проводки по сценарию «факта», соответствующе настройкой сценария и вводом еще одного документа «АУБ Ввод начальных остатков».
2.6.14.8.Для сценариев «плана», вероятно, будет только один сценарий, который «претендует» на ведение в нем прогнозного баланса («на постоянной основе») и соответственно учета проводок по УпрПлСчетов. Возможно, таких плановых сценариев вообще не будет, хотя есть и вариант, что для «проектных версий» сценариев потребуется расчет прогнозного баланса («разово») для, например, составления бизнес-плана. В любом случае для планового сценария, по которому постоянно нужен прогнозный баланс («на постоянной основе»), следует ожидать периодического введения новых документов «АУБ Ввод начальных остатков», в целях уточнения входящих остатков по счетам, которые при планировании будут неизбежно «убегать» от «реальности». Функционал устроен так, что позволяет «забыть» на плановом сценарии «старые ошибки» в планировании, путем заведения нового документа «АУБ Ввод начальных остатков», перенастройки сценария (актуальной даты ввода начальных остатков) и проведения до этой даты всех «старых» документов планирования. Хотя вариант «припомнить старое», остается, например, для «разбора полетов». Делается откат даты в настройке сценария и проведение заново «старых» документов планирования, их движения при этом «оживут». Это позволит заново анализировать данные планирования «старых» периодов в рамках набора настроенных бюджетных форм.
2.6.15.Анализ данных
Когда создано «тело» учета по сценарию - движения ЭкУр УУ за отчетный период (обороты по видам движений и/или проводки по УпрПлСчетов), встает задача анализа сформированных данных. В наработках АУБ для ЭкУр реализован функционал отражения данных, как близкий к стандартному (бухгалтерские отчеты), так и специальный, ориентированный на создание расширяемого набора настроенных бюджетных форм для автоматизации бюджетирования.
2.6.15.1.Бухгалтерские отчеты
Отметим, что бухгалтерские отчеты могут быть применены к данным сценария, только если по нему уже развернут учет проводками по УпрПлСчетов. Но как ранее говорилось (п.2.6.8.), учет проводками для плановых сценариев ведется далеко не всегда, в силу отсутствия на них «полноты» учета. Учет ЭкУр по сценарию «факта» так же может после своего запуска значительное время вестись, используя только обороты по видам движений.
2.6.15.2.В наработках АУБ для ЭкУр реализованы аналоги всех стандартных бухгалтерских отчетов из типовых решений, для проводок УУ по УпрПлСчетов, например, «АУБ Оборотно-сальдовая ведомость», «АУБ Оборотно-сальдовая ведомость по счету», «АУБ Карточка счета», «АУБ Анализ субконто», «АУБ Карточка субконто» и другие. При этом для бухгалтерских отчетов ЭкУр АУБ, выбор Сценария играет роль, аналогичную выбору Организации, в подобных отчетах из типовых решений для РУ.
2.6.15.3.Настройка бюджетных форм
Но основным в наработках АУБ для ЭкУр средством отражения данных сценария является функционал создания настроенных бюджетных форм, который может работать и «без проводок», когда учет по сценарию ведется только оборотами по видам движений. Кратко опишем состав объектов и работу этого функционала.
2.6.15.3.1.Справочник «АУБ Бюджеты» (иерархия групп и элементов) содержит расширяемый набор настроенных бюджетных форм (БФ), обеспечивающих получение данных всех необходимых бюджетов. В элементе вводится описание БФ и тип данных БФ «Обороты по видам движений» (ОВД) или «Остатки обороты по плану счетов» (ООПС). Для БФ типа ОВД указывается признак необходимости разделения статей на приходные и расходные. БФ типа ООПС работают только для сценариев «с проводками» и в значительной степени заменяемы бухгалтерскими отчетами, их функционал пропустим.
2.6.15.3.2.Справочник «АУБ Статьи бюджета» (иерархия групп и элементов, подчинен БФ типа ОВД) содержит иерархическую структуру статей бюджета (СБД). Для бюджетов, с признаком разделения статей, в каждом элементе СБД указывается тип статьи «Приход» или «Расход».
2.6.15.3.3.Справочник «АУБ Фильтры движений для статьи бюджета» (подчинен СБД) содержит набор фильтров оборотов по видам движения для статьи бюджета. Каждый фильтр «подхватывает пучок» бюджетных движений (оборотов бюджета) удовлетворяющих условиям фильтра. Все обороты, входящие в «пучки» фильтров входящих в набор, «суммируются» для СБД и образуют показатели статьи (в специализированном отчете п.2.6.15.4.), для которой указан набор.
2.6.15.3.4.Фильтр содержит признак «Отключен», если он указан, то фильтр не в активном состоянии (не «суммируются» в показателях статьи, рассматривается как «черновик»). В фильтре можно задать комментарий.
2.6.15.3.5.В фильтре для определения его «условия» задаются (подобно самому обороту бюджета п.2.6.7.) реквизиты: «Вид движения», три фиксированные аналитики («ОЗТ, СД, ЛЦО») и четыре аналитики переменного типа («Аналитика1,2,3,4»). При этом вид движения заполняется обязательно, а остальные могут быть как пустыми, или содержать группу любого уровня, так и элемент соответствующей аналитики, определяемой выбранным видом движения.
2.6.15.3.6.Оборот подходит условиям фильтра, если у него и у фильтра совпадают виды движения, если аналитики в движении совпадают с соответствующими значениями фильтра, либо «вложены» в указанные в фильтре группы аналитик по иерархии, либо в фильтре эта аналитика пустая («значит подходит любое значение соответствующей аналитики в обороте»).
2.6.15.3.7.Понятно, что формируя настройку БФ сначала структурой СБД, каждый из элементов СБД содержит набор фильтров легко ошибиться и создать противоречивую настройку, в которой оборот бюджета может попасть одновременно в различные фильтры и при этом будет учтен в показателях статей БФ два или более раз.
2.6.15.3.8.При «наполнении» структуры статей бюджета фильтрами, производится автоматизированный «контроль непротиворечивости», т.е. если в другом уже введенном фильтре какой либо статьи этой БФ, могут оказаться обороты нового (вводимого) фильтра, система покажет противоречивые фильтры и не даст сохранить фильтр в активном состоянии. Выход - это исправление текущего фильтра или тех фильтров, с кем есть противоречие, после этого структуру БФ можно изменить. Это дает возможность строить гарантировано «непротиворечивые» БФ, в которых одно и то же движение не будет учтено несколько раз по разным статьям.
2.6.15.3.9.В фильтре есть табличная часть (ТЧ) «Пересекающиеся фильтры», она содержит фильтры и их статьи БФ, которые пересекаются с данным фильтром (могут включать обороты, которые войдут и в этот фильтр). Эта ТЧ не редактируется вручную, она автоматизировано очищается, когда фильтр сохраняется в активном состоянии и не возникает «противоречивости» в БФ. Так же она автоматизировано заполняется, когда фильтр пытаются записать, но возникает «противоречивость» в БФ, при этом фильтр сохраняется в не активном состоянии (указан признак «Отключен»). Эта ТЧ позволяет оперативно разобраться и исправить возникшую «противоречивость» фильтров, переходя к редактированию «пересекающихся» фильтров (обычно к их «сужению») и повторению попытки сохранить текущий фильтр в активном состоянии.
2.6.15.4.Отчет по бюджетным формам
После завершения настройки БФ (тип ОВД), в специализированном отчете «АУБ Обороты по видам движений», можно получать и анализировать данные бюджета одного или двух (сравниваемых) сценариев по статьям БФ, с возможностью развертки по периодам и расшифровкой полученных показателей статей по аналитикам ЭкУр.
2.6.15.4.1.В отчете задаются: анализируемый Период (начало и конец, обычно - это горизонт сценария), задается Бюджет (настроенная БФ), Периодичность (если нужно разворачивать данные по периодам), выбирается Сценарий и еще возможно Сценарий сравнение, дополнительные отборы при необходимости.
2.6.15.4.2.Ранее говорилось, что при настройке структуры статей и фильтров наполнения статей реализован автоматизированный «контроль непротиворечивости». Нужно отметить, что в отчете реализован специальный сервис контроля «полноты» бюджета, позволяющий облегчить поиск движений, не вошедших в бюджет (из-за не корректной настройки структуры БФ), но которые там быть должны. Следует отметить, что в оборотных бюджетах и не должно быть «всей полноты», т.е. нет таких оборотных бюджетов, которые должны в принципе включать все возможные движения по сценарию. Такая полнота может быть в бюджетах отражающих остатки по статьям, например, ББЛ (бюджет по балансовому листу).
2.6.15.4.3.Сервис контроля «полноты» бюджета - это «помощник». Он не «гарантирует» результат, как «контроль непротиворечивости». Принцип работы следующий. В отчете есть признак «Дополнение бюджета», признак указывает, что в отчет выводятся движения, в пределах выбранных сценариев и видов движений из фильтров статей, не вошедшие в бюджет. Ожидается, что когда в фильтры БФ подбирались виды движения (по сути, справочник проводок Дт Кт п.2.6.7.), то, скорее всего, полнота была обеспечена. То есть все задействованные в бюджете виды движения (проводки) были выбраны, а вот когда при настройке фильтров их условия «сужались» выбором аналитик (групп или элементов справочников), то вероятность что-то пропустить, существенна. Запустив отчет в режиме «дополнения» (т.е. обороты, которые не попали в бюджет, но имеют те же виды движения), анализируя результат, делая его расшифровки, легко определить «пропуски» и доработать настройку БФ. На этапе создания (наработки) необходимого для управления набора БФ этот сервис будет востребован.
2.6.15.4.4.В отчете предусмотрена дополнительная возможность сохранять в файл данные рассчитанные отчетом. При этом сохраняются показатели бюджета вместе с расшифровками (в файле сохраняются настройки отчета и таблица - источник данных, полученная запросом). Эта возможность особенно важна для плановых сценариев, т.к. позволяет вернуться к анализу «старого» варианта бюджета. Это важно, потому что плановые данные «предметно мутабельны», т.к. они могут быть пересмотрены в процессе работы и это не является какой-то ошибкой процесса планирования. С другой стороны, ответственный сотрудник, принявший ранее управленческое решение на основании «ныне устаревших» плановых бюджетных данных, может оказаться в «глупом» положении. Если же у него будет сохраненный файл бюджета (вместе с расшифровками), он сможет объяснить причину ранее принятого решения.
2.6.15.5.Резюмируя средства вывода информации, следует отметить, что в наработках АУБ для ЭкУр реализован функционал, предоставляющий широкие возможности для анализа созданных данных по сценариям «плана» и «факта» и принятия управленческих решений на их основе.
2.7.Учетные цены, отклонения и себестоимость в АУБ
2.7.1.В концепции и наработках АУБ реализован определенный подход (метод) к учету стоимости материально-технических ресурсов (МТР) в УУ. В концепции АУБ запасы МТР учитывается параллельно и относительно независимо на ТехУр и ЭкУр. На ТехУр МТР учитываются по технической номенклатуре (ТехНом) (п.2.5.3.), это детальная (точная, инженерная, технологическая) управленческая номенклатура. На ЭкУр МТР выражены справочником «Объекты затрат» (ОЗТ) (п.2.5.4.), эта агрегированная (укрупненная) номенклатура, используемая для расчета фактической себестоимости за отчетный период и экономического планирования по периодам.
2.7.2.Учетные цены
В качестве метода оценки запасов как на ТехУр, так и на ЭкУр, в АУБ используются учетные цены (УЦ). Линейки УЦ для ТехУр и для ЭкУр не зависимые, для ТехУр УЦ задаются на ТехНом в разрезе типов цен, а для ЭкУр УЦ задаются на ОЗТ, и зависят от значения аналитик определяющих направление деятельности (СД) и территорию использования (ЛМЗ). При этом ОЗТ используемое в линейке УЦ для ЭкУр, должна обладать достаточной детализацией (п.2.6.12.1.2.), не быть «статейного» уровня агрегации.
2.7.2.1.С учетом разделения на уровни в АУБ, данный подход является специфической реализацией нормативного метода учета запасов.
2.7.2.2.В концепции АУБ используется три линейки УЦ, выражающие три варианта оценки стоимости (себестоимости) запасов материально-технических ресурсов (МТР), одна линейка УЦ на ТехУр и две линейки на ЭкУр - учетные цены фактической (ФактУЦ) и плановой (ПланУЦ) себестоимости.
2.7.2.3.Запасы МТР в АУБ всегда должны иметь оценку стоимости (УЦ), хотя при этом они могут быть оценены только на ТехУр (материалы, товары, сырье), на ТехУр и на ЭкУр одновременно (продукция и полуфабрикаты), только на ЭкУр (бывает редко, например, при использовании трансфертных цен на сырье, при внутренних трансфертных продажах).
2.7.2.4.Полноценный «балансовый» учет стоимости запасов МТР делается только на ЭкУр. Оценка стоимости запаса делается с учетом аналитик направления деятельности (СД) и территории использования (ЛМЗ), при этом запас сначала оценивается по данным ЭкУр исходя из ФактУЦ по ОЗТ. Если же ФактУЦ на ОЗТ нет, например, нет «в принципе» так как ОЗТ «статейного» уровня агрегации, то оценка делается по данным ТехУр исходя из УЦ на ТехУр и количественных данных по ТехНом (детальной номенклатуре).
2.7.3.Три линейки учетных цен
Использование УЦ для оценки стоимости запасов (нормативного метода) и использование параллельно трех линеек УЦ (УЦ ТехУр, ПланУЦ и ФактУЦ ЭкУр) является в АУБ частью концепции по нескольким причинам.
2.7.3.1.Методы расчета себестоимости, реализованные в типовых решениях для РУ, представляют себестоимость «постфактум», когда решения уже все состоялись. Для принятия управленческих решений на основании так или иначе рассчитанной себестоимости, она должна «явно» быть в «наличии» на момент принятия этого решения. Когда себестоимость «явно присутствует» в соответствующей линейке УЦ, тогда она и может активно использоваться и быть основанием для текущего управления.
2.7.3.2.Кроме этого только УЦ позволяют обеспечить актуальную «рыночную» оценку запасов МТР. Использование ФИФО или других методов, создает в оценке запасов некую «неопределенность», когда, например, одна номенклатура сырья может иметь параллельно разные оценки стоимости («по стоимостным партиям»), себестоимость может меняться, от того по какому алгоритму эти партии расходуются, при этом эти изменения ни как не связаны с «рыночной конъюнктурой». УЦ в АУБ, это, прежде всего, «рыночная» оценка. Она не может иметь параллельных «стоимостных партий» одного и того же МТР, не связанных с различиями, имеющими экономически обоснованную природу, например, для ЭкУр в АУБ - это территории (ЛМЗ) или бизнесы (СД). Для разных ЛМЗ и СД себестоимость одного и того же МТР может иметь в АУБ разные значения, но это не результат «математического алгоритма метода», а результат различных экономических условий использования этого МТР.
2.7.3.3.Нужна разная себестоимость
Что касается использования в АУБ трех параллельных линеек УЦ на ТехУр и ЭкУр, это связано еще с тем, что разные по характеру управленческие решения «хотят разной» себестоимости.
2.7.3.3.1.Например, в ТОС («Теория ограничений систем» Элияху Голдратт) оспаривается вообще необходимость расчета полной фактической себестоимости для принятия управленческих решений и вводится понятие TVC (Totally Variable Cost) – полностью переменные затраты. Для оперативного управления в ТОС, есть «свои резоны» использовать именно TVC. Отметим, что УЦ в ТехУр (себестоимости продукции) близки по своим значениям к TVC.
2.7.3.3.2.Концепция АУБ, «признает» «значимость» для управленческих решений данных фактической себестоимости (ФС), но только на ЭкУр.
2.7.3.3.3.На ТехУр, основной задачей которого является поддержка оперативного управления бизнесом, расчет ФС в АУБ не делается и поэтому на ТехУр только одна линейка УЦ. Делать расчет ФС на ТехУр в АУБ нецелесообразно по ряду причин.
2.7.3.3.3.1.Как уже говорилось, ТехУр обеспечивает оперативное управление, в котором ФС мало востребовано и даже, как это, например, утверждается в ТОС, может привести к ошибочным решениям.
2.7.3.3.3.2.Кроме того ФС предполагает присутствие в ней распределяемых и косвенных затрат, «точность» этого распределения будет всегда «спорной». Но ТехУр учитывает МТР по ТехНом (технической номенклатуре), а это детальная (точная, инженерная, технологическая) управленческая номенклатура, при этом возникает «диссонанс», «не соответствие, порядка точности» ТехНом и доли стоимости в ней, полученной от распределения косвенных затрат.
2.7.3.3.3.3.Но даже в части, например, «точных» сырьевых затрат, в практике редко можно встретить техпроцессы, где возможен «точный» учет расхода сырья на выпуск производственного цикла, хотя такое тоже встречается. Обычно «точный» фактический расход сырья не удается учесть в каждом производственном цикле, и списание производится все равно по «норме» из спецификации. При этом накопленное «расхождение» выявляется по итогам периода, например, по итогам месяца, в результате «цеховой» инвентаризации. Отметим, что затраты при этом «нормативные» по списанному количеству, и ФС ТехУр в части сырья, если бы даже учитывалась, все рано не была бы фактической.
2.7.3.3.3.4.Более того, даже в случае, когда есть «фактические» данные расхода в производственный цикл, еще вопрос, должны ли мы эти «необъяснимые» отличия от нормы относить на себестоимость. Есть «резон» и в позиции, что себестоимость продукции «не виновата», если в цехе что-то «напутали или украли», и правильно эту «разницу» «вынимать» из себестоимости и относить на отклонения в производстве по ЛЦО цеха.
2.7.3.3.3.5.Все отклонения в концепции АУБ являются расходами на период, а не на продукт, и по окончании периода они будут списаны на результат. Поэтому общий результат деятельности СЦО, в случае «перевода» части стоимости из себестоимости продукции в отклонения, изменится только временно и не значительно. Если возникновение отклонений «обосновано», то для эффективности УУ всегда лучше их «выделять», так как они являются «сигналами» для принятия управленческих решений.
2.7.3.3.3.6.Нужно отметить, что есть техпроцессы, в которых фактический расход сырья в производственный цикл может «легально» существенно отличаться от данных спецификации, в этом случае формировать отклонения не правильно. Это процессы, например, в которых несколько сырьевых позиций «взаимозаменяемы» по химсоставу, для расчета рецептуры полуфабриката. Спецификация тогда более нужна для нормирования, и определяет наиболее «вероятный» вариант производственного цикла. При этом в документах ТехУр, отражающих такие циклы, эти отклонения от спецификации нужно «представить» для анализа.
2.7.3.3.3.7.В любом случае расчет ФС на ТехУр «избыточен», «спорен» и не нужен для оперативного управления. Что же касается нормативной «сырьевой» себестоимости, рассчитанной по спецификациям для продукции и полуфабрикатов (ПФ), то ее «значимость» на ТехУр, для принятия ряда оперативных управленческих решений, «критически» важна.
2.7.4.Оперативные учетные цены
УЦ на ТехУр используются в АУБ как для товаров, сырья и материалов, так и рассчитываются для продукции и ПФ, они могут устанавливаться с периодичностью день. УЦ устанавливаются по типам цен, которые могут отличаться. Например, в наработках реализовано, что на каждый год устанавливается новый тип цен для УЦ ТехУр. Это нужно, чтобы не «всплыли старые» УЦ. По итогам года, если УЦ текущего года «походят» для использования в новом году, то они «осознано» переносятся на тип цен следующего года. Этот перенос цен делается с сервисами АУБ и не является трудоемким, но в тоже время он требует заполнения нового документа «АУБ Установка цен тех ном» и соответствующей ответственности сотрудника создавшего документ.
2.7.4.1.Для сырья и материалов УЦ ТехУр можно устанавливать хоть при каждом поступлении по новым ценам, но в концепции АУБ, изменение УЦ правильно делать, если эти новые цены поступления связаны с изменившейся «рыночной конъюнктурой». Если это не так, то и УЦ ТехУр менять не правильно, в АУБ при этом образуются отклонения на счет 16.03 (Отклонения по поступлению ОЗТ), которые сигнализируют о «качестве» работы отдела снабжения. Кроме этого продукция «не виновата», если в силу какой-то ошибки или злоупотребления цена покупки существенно отличается от «рыночных» УЦ ТехУр.
2.7.4.2.Хотя для продукции и ПФ «главной» учетной ценой для оценки стоимости запасов является цена ЭкУр (ФактУЦ), в АУБ УЦ ТехУр на них так же рассчитывается. Пересчет УЦ ТехУр продукции и ПФ делается, при каждом изменении цен сырья, документом «АУБ Установка цен тех ном».
2.7.4.2.1.УЦ ТехУр для продукции и ПФ рассчитывается на ТехНом на основании заданной для нее «Спецификации технической номенклатуры». Поэтому это «точная» «детальная» «сырьевая» нормативная себестоимость. В практике иногда в спецификации вводятся «псевдо» ТехНом услуг с УЦ отражающими сдельные расценки по зарплате.
2.7.4.2.2.В наработках АУБ, для расчета УЦ ТехУр продукции и ПФ используется алгоритм, в котором сначала делаются четыре уровня (передела) разузлования по спецификациям. Для ТехНом (продукции) в которой этого оказалось не достаточно, алгоритм делает итерации пересчета УЦ, пока не будет обеспечена их «сходимость» или наберется максимально допустимое количество итераций.
2.7.4.3.Отметим, что рассчитанная УЦ ТехУр для продукции (нормативная «сырьевая» себестоимость), имеет свою «управленческую ценность», хотя она и не используется для оценки запасов по стоимости (используется ФактУЦ ЭкУр). УЦ ТехУр для продукции позволяет принимать верные решения, например, при «ценовой войне», когда цены продажи могут снижаться и ниже ФактУЦ. Она дает «точную нижнюю грань», ниже которой торговля уже будет давать «чистый убыток», т.к. наценка от УЦ ТехУр отрицательная (наценка от УЦ ТехУр, аналог в ТОС - проход на единицу продукции «Throughput per unit»).
2.7.4.4.Таким образом, УЦ для ТехНом используемой в операциях на ТехУр в АУБ есть всегда. Вне зависимости от того, что это: товары, сырье, материалы, услуги, продукция или ПФ.
2.7.4.4.1.Однако, из этого правила есть исключение - это «обобщенная» ТехНом. Допускается, даже на «детальном» ТехУр «обобщать» номенклатуру. Например, для прочих расходных материалов (канцелярские товары) или при покупке «разовых» «недорогих» ОС.
2.7.4.4.2.УЦ на «обобщенную» ТехНом не устанавливается, но она не должна учитываться как складской запас. Либо она сразу списывается при покупке в затраты, либо «переводится» в учет ОС как отдельный объект. В том и другом случае ее оценка в учете делается не по УЦ, а по фактической цене от поставщика. Если МТР должен учитываться на ТехУр как складской «оборотный» запас, то УЦ у него должно быть.
2.7.5.Экономические учетные цены
Для ЭкУр себестоимость в АУБ изначально предполагает наличие распределяемых и косвенных затрат. Их размер и состав в продукции и ПФ, конечно определяется принятой в УУ системой учета затрат и калькуляции себестоимости («директ-костинг» или «стандарт-костинг») но в любом случае это не «чистая» «сырьевая» себестоимость как в УЦ ТехУр (возможно содержащая сдельную зарплату) подобная TVC в ТОС.
2.7.5.1.В ЭкУр две линейки УЦ ПланУЦ и ФактУЦ, они обе учитывают «распределяемые» затраты, но отличаются по своей экономической «природе».
2.7.5.2.Плановые цены и калькуляции продукции
ПланУЦ это те цены себестоимости, которые «должны быть», на основании состава нормативных «входящих» затрат определяемых экономистами предприятия. ПланУЦ рассчитываются на основании плановой калькуляции продукции или ПФ. Плановая калькуляция «привязана» (на выходе) к направлению деятельности (СД) и территорий (ЛМЗ), в котором это производство запланировано. В своем составе (на входе) она содержит данные потребленных ресурсов (ОЗТ), в количественном и суммовом выражении, а также СД и ЛМЗ, из которых потреблен ресурс.
2.7.5.2.1.В наработках АУБ, в документе «АУБ Закрытие месяца» реализован итерационный алгоритм для расчета ПланУЦ продукции и ПФ по данным плановых калькуляций.
2.7.5.2.2.Калькуляция задается на ОЗТ, в разрезах СД и ЛМЗ, по составу «входу» калькуляции определяются входящие ОЗТ также в разрезах СД и ЛМЗ входа с ресурсами количества и сумма. Если входящий ОЗТ имеет «статейный» уровень агрегации или на него нет ПланУЦ, то стоимость в итерации алгоритма по этому ресурсу (входу) определяется только указанной суммой. Если по ОЗТ предусмотрена ПланУЦ (п.2.6.12.1.2.), то входящая стоимость по этому ресурсу рассчитывается на каждой итерации алгоритма от входящего количества и ПланУЦ текущей итерации. Для ПланУЦ ОЗТ алгоритм делает итерации пересчета, пока не будет обеспечена «сходимость» ПланУЦ или количество итераций достигнет максимально допустимого.
2.7.5.2.3.При проведении документа «АУБ Закрытие месяца» расчет ПланУЦ всегда делается перед запуском алгоритма расчета ФактУЦ. В наработках АУБ, ПланУЦ и данные плановых калькуляций являются основой механизма «распределения» затрат производства на выпуск продукции и ПФ в разрезе территорий (ЛМЗ) и направлений деятельности (СД).
2.7.5.3.Цены фактической себестоимости
ФактУЦ это данные фактической себестоимости по умолчанию с предыдущего периода. Но в течение текущего периода именно они используются для оценки стоимости запасов на ЭкУр и принятия соответствующих управленческих решений. Бывает, что в силу некоторых причин («форс-мажор» на производстве), расчет даст «плохие» ФактУЦ, тогда для оценки запасов их в АУБ использовать не рекомендуется, и вместо них можно установить, например, ПланУЦ или оставить «старую» ФактУЦ с прошлого периода.
2.7.5.3.1.По итогам периода (месяц) документом «АУБ Закрытие месяца» производится расчет ФС выпускаемой продукции и ПФ. По умолчанию результат расчета (ФС) устанавливается на следующий период в качестве учетных цен ФактУЦ, делается переоценка стоимости продукции и ПФ.
2.7.5.3.2.Расчет фактической себестоимости
В наработках АУБ, при расчете фактической себестоимости (ФС) реализован определенный подход к учету и распределению затрат отнесенных в производство. Производственные затраты анализируются в составе пересечений СД и ЛМЗ (СДхЛМЗ), то есть отдельно для каждого направления деятельности и территории производства.
2.7.5.3.3.По СДхЛМЗ определяется выпущенная за период продукция и ПФ. Собранные на СДхЛМЗ затраты распределяются на выпуск по принципу - «по плановой калькуляции, сначала затраты распределяются кто сколько хочет, оставшиеся затраты, кто сколько стоит».
2.7.5.3.3.1.ОЗТ списанные на СДхЛМЗ ищутся во «входах калькуляций» выпущенной продукции и если они там присутствуют, то распределяются с соответствующим весом («стоимостью входа») - это и есть «кто сколько хочет». Если мы хотим что бы какая то затрата (ОЗТ) вне зависимости от ее «уровня агрегирования» попала в выпуск определенной продукции, она должна быть во входе ее калькуляции, при этом если в СДхЛМЗ параллельно выпускалась другая продукция которая «не хочет» этих затрат, то она их и «не получит».
2.7.5.3.3.2.Те затраты, которые «упали» на СДхЛМЗ и которых «никто не хочет» (их нет на входе калькуляций выпущенной продукции и ПФ в этом СДхЛМЗ), все равно должны распределиться. Они распределяться пропорционально плановой стоимости ПланУЦ и количеству выпуска, хотя это и «не порядок», что они не учтены во входе ни одной из калькуляций выпущенной продукции.
2.7.5.3.4.Таким образом, плановая калькуляция и рассчитанная на ее основе ПланУЦ, задают механизм распределения на СДхЛМЗ и важны для правильного расчета ФС. Но уделяя внимание калькуляциям мы «убиваем двух зайцев», и плановая себестоимость ЭкУр будет «правильнее» рассчитана, и фактическая, за счет более точного распределения затрат на выпуск в СДхЛМЗ, будет точнее.
2.7.5.3.5.При расчете ФС, реализован итерационный алгоритм (подобно РАУЗ в типовых решениях), в котором на каждом цикле итерации стоимость собирается по СДхЛМЗ и распределяется на выпуск на основе калькуляций. Итерации продолжаются, пока не будет обеспечена сходимость расчета ФактУЦ выпущенной продукции и ПФ.
2.7.5.4.Подход к учету себестоимости
Рассчитанные ФактУЦ естественно будут несколько отличаться от тех, которые по факту использовались, как учетные цены ЭкУр и были установлены с предыдущего периода. Если их задним числом «переназначить» и провести все документы выпуска и затрат, они «точно подойдут», но это не рекомендуется делать в концепции АУБ.
2.7.5.4.1.В течение завершенного периода управленческие решения принимались на основании тех ФактУЦ, которые были установлены, и ставить управленцев в «глупое» положение «подменив» им ФактУЦ «задним числом» не правильно.
2.7.5.4.2.В АУБ, при закрытии периода документом «АУБ Закрытие месяца», рассчитываются специальные «производственные» отклонения, возникшие в результате разницы в учетной цене текущего периода и той ФактУЦ, которая получена по расчету. Эти отклонения списываются на счет 16.01 (Отклонения в производстве) и потом сразу относятся на результат. Поэтому с точки зрения показателей деятельности различий практически нет, но сами эти отклонения несут важную управленческую информацию. Их наличие и величина, говорит о том, что у нас, например, «подпрыгнула» себестоимость единицы продукции, значительное отклонение сигнализирует о необходимости дополнительного анализа затрат и выпуска, сравнения их по периодам. Если же отклонения не значительны, то это говорит о том, что причин для беспокойства нет. Таким образом, расчет этих отклонений важен для управления, а так как они все равно списываются на результат, нет необходимости заменять «задним числом» использованную в течение периода учетную цену ФактУЦ, рассчитанной «точной ценой себестоимости».
2.7.6.Следует также отметить, что в концепции АУБ есть широкие возможности для использования трансфертных цен передачи МТР между направлениями деятельности (СД) на ЭкУр. При этом у СД получателя, на ОЗТ ФактУЦ будет не «расчетная», а «назначенная» (ФактУЦ могут отличаться в зависимости от СД и ЛМЗ). Есть специальный документ «АУБ Трансферт МТР», который производит такую «внутреннюю» продажу между «бизнесами» СЦО. Тогда учетная цена ФактУЦ получателя будет ценой продажи у СД «продавца», при этом «продавцу» будет начислена в УУ выручка по трансферту. Этот функционал востребован, если в СЦО используется экономическая модель УУ с применением внутренних трансфертных продаж между направлениями деятельности СЦО.
2.8.Объекты имущества в АУБ
2.8.1.Ранее писалось (п.2.6.12.5.), что учет ОС и других внеоборотных активов ведется на ЭкУр в АУБ агрегировано - группами ОС, имеющими однородный состав и назначение. Группы ОС отражаются на ЭкУр в составе ПЗТ (Потоков затрат) и привязке к направлению деятельности (СД) и территории (ЛМЗ), в которых они используются. На ЭкУр в АУБ есть возможность настройки амортизации для группы ОС отраженной в этом ПЗТ. Агрегированный учет ОС по ПЗТ на ЭкУр используется для целей экономического планирования и расчета фактических результатов деятельности СЦО по периодам.
2.8.2.Для целей оперативного управления, детальный управленческий учет (УУ) ОС и другого имущества, ведется в АУБ на ТехУр в подсистеме «Управление имуществом» в составе «Объектов имущества» (ОИ). ОИ в АУБ – это обособленная единица имущества предприятия, имеющая стоимость, обычно используемая в основной деятельности. По ОИ в АУБ учитывается оценочная (балансовая) стоимость, амортизация и износ. Каждому ОИ устанавливается уникальный инвентарный номер, который предлагается физически нанести на соответствующий объект.
2.8.3.Все имущество СЦО, не входящее в состав оборотных средств, подлежит «строгому» и «детальному» УУ в составе ОИ на ТехУр, вне зависимости от того стоит ли оно в РУ на балансе («оформлено») по какой либо организации (юр. лицу, где оно учтено в РУ). В практике бывает, что некоторые ОС имеют «сложную» историю появления и «оформлять» их в РУ нет смысла, а в тоже время они важны для деятельности предприятия, поэтому их «строгий» учет необходим.
2.8.4.Рыночная оценка ОС
Отметим, что «рыночная» оценка стоимости ОС, может существенно отличаться от данных из РУ. Более того, практика показывает, что в течение, например, пяти лет, рыночная оценка может уже в разы отличаться от, остаточной стоимости по данным РУ.
2.8.4.1.В АУБ есть связь ОИ с аналитиками ЭкУр. Для ОИ в учете на ТехУр может и, после инициализации учета в ЭкУр, должна делаться привязка к аналитикам ЭкУр. То есть ОИ «знает», в составе какого ПЗТ, в каком СД и по какому ЛМЗ он отражен на ЭкУр.
2.8.4.2.Для данных ЭкУр по ПЗТ в СД и ЛМЗ, показатели «связанных» с ними ОИ являются их «обеспечением», «наполнением». Это позволяет, при переоценке ОИ до «рыночной» стоимости, корректировать агрегированную стоимость, учтенную на ЭкУр по ПЗТ в СД и ЛМЗ, до ее актуального «рыночного» значения. Понятно, что оценить «рыночную» стоимость можно только для «детального» ОИ, а не «агрегированного» ПЗТ.
2.8.4.3.Для поддержания в УУ «рыночной» стоимости внеоборотных активов, в АУБ рекомендуется периодическая переоценка ОИ и корректировка данных ТехУр и ЭкУр. Например, в соответствии с МСФО (IAS 16 п. 34) один раз в 3 - 5 лет, а для некоторых классов ОИ ежегодно.
2.8.5.Для детального отражения ОИ на ТехУр важно учитывать, что имущество может быть в очень разном качественном состоянии. Даже «номинально» одно и то же ОС (оборудование, автомобиль), одного и того же года выпуска, может быть для целей своего использования совершенно в разном техническом состоянии. При этом наборы свойств, описывающих состояние ОИ, могут сильно отличаться для разных классов имущества.
2.8.6.Кроме этого имущество предприятия является причиной значительных расходов, связанных с его обслуживанием и ремонтом. Эти средства в некоторых видах деятельности составляют основную долю материальных затрат. Эффективность оперативного управления такими затратами в значительной степени определяет успешность самой этой деятельности.
2.8.7.Детальный учет ОС
Кратко опишем реализованный в наработках АУБ состав основных объектов и функционал детального УУ имущества на ТехУр.
2.8.7.1.Справочник «АУБ Классы технической номенклатуры» (иерархия групп и элементов) содержит универсальный классификатор материально-технических ресурсов (МТР) на ТехУр, используемый как для оборотных, так и для внеоборотных активов предприятия. Ссылки на справочник классов используются как в «детальной» технической номенклатуре (ТехНом), таки и в ОИ.
2.8.7.1.1.Группы классов определяют «категории» имущества, определяющих близкие классы имущества. Например, категории: «Энергооборудование силовое», «Оборудование лаборатории», «Компьютерная техника» и т.д.
2.8.7.1.2.Наименование класса должно на «понятном языке» отразить, что это за МТР. В некотором роде, это справочник разрешенных терминов для второго названия ОИ и ТехНом. Это необходимо, так как часто бывает, что перечень наименований ОИ и ТехНом понятен только узкому специалисту. Менеджеру или экономисту бывает трудно понять, что представляет объект, который назван определенными техническими терминами. Для разъяснения сущности ОИ и ТехНом, в них указывается ссылка на класс, который характеризует (пусть и обобщенно), что это такое. Например, названия классов: «Высоковольтная аппаратура», «Прессы и разрывные машины», «Источники бесперебойного питания» и т.д.
2.8.7.1.3.Для задач «классификации» имущества, классы в АУБ рекомендовано выстраивать так, что бы наборы свойств у ОИ и ТехНом в них входящие были близки или одинаковы. Понятно, что какие то значения свойств, для разных ОИ и ТехНом будут отличаться, но их перечни (это связано с функционалом назначения свойств, для ОИ и ТехНом) должны быть одинаковые.
2.8.7.2.Справочник «АУБ Объекты имущества» (иерархия групп и элементов) содержит ОИ–обособленные единицы имущества предприятия. Желательно, что бы группы справочника «повторяли» группы классов, а класс образовывал группу для элементов ОИ. Для ОИ задается (автоматизировано на основании класса и модели ОИ) код, который и является Инвентарным номером (п. 2.8.2.). В элементах справочника задается класс (обязательный реквизит) и модель ОИ (ссылка на ТехНом, может быть не задана). В элементе ОИ можно сохранить изображение имущества (фото).
2.8.7.2.1.Модель в ОИ указывать не обязательно, это нужно делать, когда на предприятии есть многочисленные ОИ одной и той же номенклатуры (ТехНом), которая и будет «моделью» ОИ. Это важно, потому что тогда можно значительную часть свойств характеризующих ОИ указать только для модели и для каждого ОИ не задавать.
2.8.7.3.План видов характеристик «АУБ Целевые наборы свойств» определяет наборы свойств, описывающие ОИ, для какой либо цели, задачи или учета. Наборы свойств «назначаются» по типу, например для ОИ или для ТехНом, то есть для какого типа (справочника) этот набор свойств. Также набор может «назначаться» по классу имущества, то есть, для какой группы объектов этого типа назначены свойства.
2.8.7.4.План видов характеристик «АУБ Свойства объектов» определяет свойства для описания ОИ и ТехНом. Перечни свойств, которые нужно указать, определены в наборах. Для ОИ задаются необходимые («назначенные») значения свойств характеризующих состояние ОИ. Значения свойств заданных для ОИ имеют сохраняемою историю значений.
2.8.7.5.Справочник «АУБ Состояния имущества» (иерархия групп и элементов) характеризует на ТехУр территориальное и функциональное назначение использование имущества предприятия (ЭкУр может и не вестись определенный начальный период).
2.8.7.6.Все ОИ в АУБ документами ТехУр устанавливаются в определенные состояния (п.2.8.7.5.), с указанием оценочной стоимости, амортизации и износа, задается МОЛ (Материально ответственное лицо). При этом могут (при необходимости, для ЭкУр) указываться «бюджетные» аналитики ЭкУр, с которыми связан данный ОИ (п.2.8.4.1.).
2.8.8.Учет расходов на ОС
В АУБ на ТехУр предусмотрен функционал нормирования контроля расходов, связанных с его обслуживанием и ремонтом (п.2.8.6.). Он дорабатывается в конкретном проекте автоматизации ТехУр для СЦО. Опишем общий подход, в наработках.
2.8.8.1.Справочник «АУБ Виды норм расхода» содержит предопределенные элементы определяющие виды нормирования расходов на ОИ (определяет способы расчета нормативного расхода ресурса).
2.8.8.2.Регистр сведений «АУБ Нормы расхода на ОИ» задает нормы расхода на ОИ для класса, модели или ОИ, по виду нормирования. Определяется расходуемая по норме номенклатура (материал, запасная часть) и числовое значение нормы.
2.8.8.3.Оборотный регистр «АУБ Расходы на объекты имущества» отражает для ОИ по определенному виду нормирования и расходуемой номенклатуре (материал, запасная часть), величину расхода по норме и по факту.
2.8.8.4.В документах ТехУр, которые производят списание в затраты запасов, можно указать (опционально) ОИ на который списывается материал, при этом регистрируется фактический расход. В документах отражающих наработку (выпуск) может рассчитываться расход по норме по определенному виду нормирования и отражаться в регистре.
2.8.8.5.В дальнейшем анализируются расходы по норме и по факту на ОИ по видам нормирования и израсходованным запасам. Если учет наработки для ОИ по виду нормирования не ведется и не рассчитывается расход по норме, то отражаются только расходы по факту на ОИ, такие как расходы на ремонт, установленные запчасти и другие. Даже учет только фактических затрат на ОИ позволит в сравнительном анализе обнаружить возможные «злоупотребления» и завышения издержек, связанных с обслуживанием и ремонтом ОИ.
2.8.9.Резюмируя учет ОИ, следует отметить, что как уже говорилось (п.2.3.3.) функционал ТехУр сильно зависит от отраслевой специфики, и в конкретных проектах автоматизации он может существенно дорабатываться для обеспечения эффективности оперативного управления. В наработках АУБ реализован функционал учета ОИ, который может быть хорошей основой для учета ОИ на ТехУр в конкретных проектах автоматизации.
2.9.Зарплата в УУ АУБ
2.9.1.Зарплата является основным инструментом мотивации сотрудников предприятия к эффективному труду. Оперативное управление мотивацией сотрудников в значительной степени определяет эффективность управления бизнесом в целом и должно поддерживаться сервисами управленческого учета (задачи ТехУр УУ).
2.9.2.С другой стороны, оплата труда является существенной, а для некоторых бизнесов основной составляющей затрат предприятия, поэтому учет зарплаты обязателен для определения основных показателей бизнеса, таких как фактическая себестоимость выпускаемой продукции, доходность различных направлений деятельности, управленческая прибыль за период (задачи ЭкУр УУ).
2.9.3.Функционал отражения зарплаты в УУ в значительной степени определяется отраслевой спецификой, подходами к оформлению деятельности, спецификой управления определяемой владельцами и высшим руководством предприятия.
2.9.4.В концепции АУБ сформировался ряд различных подходов к автоматизации зарплаты (ЗП) в УУ. Выбор подхода зависит от специфики управления и определяется вариантами выбора в двух условиях.
2.9.5.Сложность ЗП
Первое условие определим как «Сложность ЗП» и соответственно варианты выбора, это ЗП «сложная» и «простая».
2.9.5.1.В зависимости от специфики управления уровень сложности функционала расчета ЗП может быть очень разным. Как правило, ЗП имеет постоянную и переменную составляющие. Постоянная составляющая, определяется обычно окладом и «классическими» методами начисления, связанными с учетом рабочего времени. Функционала расчета переменной составляющей ЗП может сильно зависеть от специфики управления и определяться оперативными показателями деятельности ТехУр УУ.
2.9.5.2.Под «простой» будем понимать ЗП, в которой механизм начисления не зависит «напрямую, сильно» от оперативных данных ТехУр УУ. ЗП тогда представляет оклад плюс «назначаемые» премиальные (переменную составляющую).
2.9.5.3.Под «сложной» определим ЗП, в которой функционал расчета переменной составляющей «сильно» зависит от оперативных данных ТехУр УУ.
2.9.5.3.1.Это может быть разного рода «сдельщина» на производстве, учитывающая индивидуальную выработку рабочих. Либо это вообще сложная мотивация, ориентированная на целый ряд оперативных данных ТехУр УУ, рассчитываемая по сложным алгоритмам и требующая в функционале ТехУр УУ специальной «архитектуры поддержки» ее расчета.
2.9.5.3.2.Например, переменная ЗП менеджеров продаж составляет некоторый процент от величины прохода по ТОС по их сделкам за месяц. Проход рассчитывается как оплаченный маржинальный доход (оплаченная суммарная наценка от УЦ ТехУр) по сделкам. Понятно, что при этом необходим «специальный» функционал ТехУр УУ для поддержки такой мотивации. Никакими «переделками» типового функционала здесь ничего сделать нельзя, а в концепции АУБ на ТехУр такие задачи автоматизации решаются.
2.9.5.3.3.В реальном секторе у значительной части сотрудников предприятия ЗП как раз «сложная». Часто только «сложная» ЗП позволяет создать мотивацию более «согласованную» с «эффективностью» самого бизнеса.
2.9.5.3.4.В реальности, эта необходимая для бизнеса «сложность» расчета переменной части ЗП, «закопана» в «екселях» у сотрудников ОТИЗ, руководителей производственных участков и экономистов. По итогам месяца специалист, рассчитывающий переменную часть ЗП, «достает из екселя» некоторую сумму и отдает для начисления. Проверить эти данные сложно, при такой ситуации возможны ошибки, сильно выражен «человеческий фактор».
2.9.5.3.5.Ситуация, когда ЗП рассчитывается отдельно в «екселе», в концепции АУБ считается не правильной. Она допустима только как временная, при развитии функционала ТехУр УУ.
2.9.5.3.6.Правильно, когда сами «управленческие» документы ТехУр УУ, определяющие выработку, выпуск или другие события ТехУр УУ, производят начисления ЗП. Начисление ЗП (переменной) делается на основании внесенных в документ данных и является для документа «дополнительным» функционалом. Достоверность таких начислений «сложной» заплаты, их «согласованность» с показателями отраженными в ТехУр УУ, несравнимо выше, чем при расчете отдельно в «екселе».
2.9.6.Оформление ЗП
Второе условие определим как «Оформление ЗП» с вариантами выбора - ЗП «оформленная» и «смешанная».
2.9.6.1.Будем считать ЗП «оформленной», если взаиморасчеты по ней полностью представлены в РУ, по какой либо из организаций (юр. лицу, где они учтены в РУ).
2.9.6.2.Под «смешанной» будем понимать зарплату, в которой лишь часть расчетов представлена в РУ, или эта вообще «чисто управленческая» ЗП и в РУ никак не учитывается.
2.9.6.3.Выбор этого условия определяется владельцами и руководством предприятия. Он зависит от подходов к оформлению деятельности и налоговой оптимизации, специфики управления бизнесом.
2.9.7.Разберем различные подходы к автоматизации ЗП в АУБ в зависимости от выбора в двух описанных условиях.
2.9.7.1. ЗП «простая» и «оформленная»
2.9.7.1.1.В этом подходе на «детальном» ТехУр вообще не нужен учет ЗП, так как все взаиморасчеты ведутся в РУ и они достаточны для оперативного управления мотивацией. Для УУ в АУБ «нужны» только «агрегированные» затраты по ЗП в разрезе аналитик ЭкУр, таких как ОЗТ, СД, ЛМЗ. Это нужно для определения «экономических» показателей бизнеса на ЭкУр.
2.9.7.1.2.Задача автоматизации в этом подходе сводится к «укрупненному переносу» затрат по ЗП из РУ в УУ на ЭкУр и «наделению» их управленческими аналитиками ЭкУр. Взаиморасчеты ЗП по сотрудникам в УУ в этом подходе не ведутся.
2.9.7.2. ЗП «простая» и «смешанная»
2.9.7.2.1.В этом подходе в УУ ведется «полнофункциональный» учет ЗП. На ТехУр УУ ведется учет взаиморасчетов по ЗП для каждого сотрудника.
2.9.7.2.2.Расчеты в РУ по ЗП носят «формальный» характер. Выплата по «оформленной» части ЗП в РУ делается по отдельным ведомостям, либо вообще по безналичному расчету.
2.9.7.2.3.Данные затрат по ЗП в УУ «поднимаются» на ЭкУр из ТехУр «онлайн» непосредственно из первичных документов начисления ЗП в УУ. В документах начисления ЗП в УУ указываются все нужные для ЭкУр управленческие аналитики, такие как ОЗТ, СД, ЛМЗ и другие. Это стандартный ранее описанный прием в АУБ (п.2.6.4.). Это позволяет получить все данные учета на ЭкУр необходимые для определения «экономических» показателей за период.
2.9.7.2.4.Отметим, что хотя в этом подходе ЗП «простая», но так как в УУ «полнофункциональный» учет ЗП, на ТехУр УУ должен быть представлен весь необходимый «набор» объектов для учета ЗП в УУ. С другой стороны, так как ЗП «простая», то этот «набор» объектов будет обладать относительной «отраслевой функциональной независимостью». В наработках АУБ реализован необходимый «набор» объектов для учета «простой» ЗП в УУ.
2.9.7.2.5.Так же отметим, что функционал «сложной» ЗП обладает «сильной» отраслевой зависимостью. Но имеющийся в наработках АУБ «универсальный» функционал для «простой» ЗП, может быть базой (основой) для развития «отраслевого» функционала ЗП на ТехУр УУ.
2.9.7.3. ЗП «сложная» и «оформленная»
2.9.7.3.1.Так как в этом подходе ЗП «сложная», то функционал расчета переменной составляющей «сильно» зависит от оперативных данных ТехУр УУ. Поэтому необходимо, что бы расчет начислений для переменной части ЗП делался в АУБ сервисами ТехУр.
2.9.7.3.2.С другой стороны, так как все взаиморасчеты по «оформленной» ЗП ведутся с сотрудниками в РУ, то их дублирование на ТехУр не обязательно и избыточно.
2.9.7.3.3.Функционально «минимальный» вариант при этом, это расчет сервисами ТехУр переменной части «сложной» ЗП. Рассчитанные данные начислений переменной части сохраняются в ТехУр «оборотами», при этом сами начисления ЗП в ТехУр не делаются.
2.9.7.3.4.Потом данные расчета переменной части ЗП передаются в РУ, где эти начисления добавляются документами РУ к данным постоянной части ЗП. При этом в РУ получаем полные начисления «оформленной» ЗП.
2.9.7.3.5.Потом, для решения задач ЭкУр, делается «укрупненный перенос» затрат по ЗП из РУ в УУ на ЭкУр и «наделению» их управленческими аналитиками ЭкУр, подобно п. 2.9.7.1.2. (ЗП «простая» и «оформленная»).
2.9.7.4. ЗП «сложная» и «смешанная»
2.9.7.4.1.Этот подход является развитием подхода п.2.9.7.2. (ЗП «простая» и «смешанная»), все действия по учету ЗП делаются аналогично.
2.9.7.4.2.Развитие получает только функционал ТехУр УУ расчета переменной составляющей «сложной» ЗП. Именно в расчете переменной части проявит себя «сложность» ЗП. При этом в функционале расчета ЗП отразится «отраслевая» специфика деятельности.
2.9.7.5. Комбинированный вариант
Комбинированный вариант, когда в основном ЗП «оформленная», а для малой группы сотрудников «смешанная».
2.9.7.5.1.Вести учет взаиморасчетов по ЗП в УУ для всех сотрудников, из-за малой группы (МГ) со «смешанной» ЗП, в этом подходе видится избыточным.
2.9.7.5.2.Можно рассматривать «управленческую» составляющую «смешанной» ЗП этой МГ, как «добавочную» часть ЗП. При этом вести в УУ «полнофункциональный» учет ЗП только для МГ и только по этой «добавочную» части.
2.9.7.5.3.Тогда этот подход можно рассматривать как «сумму» подходов. Например, по «оформленной» ЗП подхода п.2.9.7.1. и по «добавочной» части ЗП МГ подхода п.2.9.7.2.
2.9.7.5.4.Взаиморасчеты ЗП по сотрудникам распадаются в этом подходе на два потока.
2.9.7.5.4.1.По «оформленной» части ЗП взаиморасчеты ведутся в РУ для всех сотрудников.
2.9.7.5.4.2.По «добавочной» части ЗП учет взаиморасчетов ведется только для МГ на ТехУр УУ.
2.9.7.5.5.Для решения задач ЭкУр данные по ЗП также «суммируются».
2.9.7.5.5.1.По «оформленной» части ЗП делается «укрупненный перенос» затрат по ЗП из РУ в УУ на ЭкУр и «наделению» их управленческими аналитиками ЭкУр, подобно п. 2.9.7.1.2.
2.9.7.5.5.2.По «добавочной» части затраты по ЗП в УУ «поднимаются» на ЭкУр из ТехУр непосредственно из первичных документов начисления ЗП МГ в УУ. При этом документы по ЗП ТехУр делают начисления только «добавочной» части ЗП МГ, и в них указываются все нужные аналитики ЭкУр, такие как ОЗТ, СД, ЛМЗ и другие.
2.10.Учет сделок, оперативное планирование и взаиморасчеты по сделкам в АУБ
2.10.1.Одним из ключевых понятий «детального» учета на ТехУр в АУБ является понятие «сделки». Под сделкой в концепции системы АУБ понимается - фактически принятые на себя обязательства внутренними и/или внешними для предприятия лицами.
2.10.2.В сделке присутствует некоторая «двойственность», с одной стороны, заключение сделки является фактически совершенным событием, с другой стороны, все данные содержащиеся в ней носят плановый характер и касаются будущих событий. Однако плановые данные сделки не являются «пассивным» прогнозом, это чьи то обязательства («обещания»), поэтому сделка «больше» чем просто план.
2.10.3.Таким образом, учет сделок в АУБ - это учет фактически принятых обязательств. В концепции АУБ, для обеспечения эффективности оперативного УУ на ТехУр, учет сделок считается необходимым. В архитектуре автоматизации на ТехУр необходимо создать объекты для сделок различного вида, реализовать функционал поддержки и контроля исполнения содержащихся в них обязательств.
2.10.4.Инициирующее событие сделки
Сделка обычно содержит целый комплекс взаимосвязанных плановых событий, отражающих принятые по ней обязательства. В сделке можно выделить главное («инициирующее») событие, которое определяет «цель» сделки.
2.10.4.1.Есть два основных вида «инициирующих» событий. Первый вид, это события удовлетворения внешнего спроса (потребности) покупателей продукции предприятия. Второй, это события обеспечения внутренней потребности («спроса») предприятия в материально-технических ресурсах (МТР).
2.10.4.2.Соответственно можно определить два вида сделок - сделки «продажи», связанные с удовлетворением внешнего спроса (потребности), и сделки «закупки», для обеспечения внутренней потребности.
2.10.4.3.Документы сделок должны содержать данные этих «инициирующих» обязательств, а также данные последующих плановых событий связанных с их выполнением.
2.10.5.При оперативном планировании на ТехУр, данные планов полученные «по сделкам», нужно дополнять «прогнозными» данными, для обеспечения необходимой полноты. Но часть плана созданная «по сделкам», и часть на основании «прогнозных» данных, должны иметь разный «статус» и различаться в функционале.
2.10.6.Отметим, что функционал ТехУр УУ для сделок обладает сильной «отраслевой» зависимостью. Для разных отраслевых решений учитываемые виды сделок и их архитектура могут значительно отличаться. Но решения, сделанные для одних отраслей, могут быть базой («источником» функционала) при создании «функциональной сборки» ТехУр УУ для автоматизации другой отрасли.
2.10.6.1.В концепции АУБ утверждается, что функционал ТехУр для различных отраслей может и «должен» различаться, но это «вынужденная» мера и если возможна «однородность» функционала, для различных отраслевых решений, то лучше ее придерживаться.
2.10.7.Пример функционала сделки (продажа ЖБИ)
Для демонстрации концепции, рассмотрим пример сделок «продаж» в наработках АУБ для отраслевого решения автоматизации производства ЖБИ, сокращенно разберем функционал и учетный процесс.
2.10.7.1.В наработке АУБ (для ЖБИ) сделка «продаж» отражается документом «АУБ Заказ план производства» (Заказ). Он содержит заказанную покупателем продукцию с датами отгрузки, план ее производства в привязке к оборудованию и датам выпуска, график оплаты заказа, план потребления на выпуск сырья и ПФ по датам, транспортные услуги доставки, последующие корректировки заказа.
2.10.7.2.Также заказ, как и большинство других документов АУБ, содержит сервис учета принятия по нему предусмотренных управленческих решений ответственными лицами, с защитой (типа электронной подписи) и увязкой прав на действия с документом.
2.10.7.3.Заказ может быть разных видов - фиксированный, рамочный и прогноз.
2.10.7.3.1.Фиксированный, это вид, при котором обязательства по оплате, производству и по отгрузкам для сделки определены полностью. Только для этого вида заказа резервируются остатки продукции для покупателя. Оборудование, задействованное в плане производства по заказу, закрывается для использования в других планах на даты выпуска.
2.10.7.3.2.Рамочный, это «не полный» заказ. Для него определяется только график платежей, ассортимент продукции и устанавливаются цены по этой сделке. Объемы отгрузки могут варьироваться и указываются только для планирования. Резервирование продукции и оборудования по заказу не делается.
2.10.7.3.3.Заказ вида прогноз - это вообще не сделка, когда покупатель просит дать ему счет, но не гарантирует его оплату («постарается оплатить»), соответственно и предприятие не берет на себя обязательств по ценам и срокам отгрузки («постарается выполнить»). Хотя для оперативного планирования данные заказа учитываются.
2.10.7.4.План выпуска и расчет сроков
Основной вид сделки для ЖБИ это фиксированный заказ. Только для этого вида возможно автоматизированное создание плана-графика выпуска по «свободному» оборудованию и расчет сроков отгрузки. Опишем учетный процесс только для этого вида.
2.10.7.4.1.Покупатель у менеджера продаж запрашивает ассортимент, объемы продукции, обозначает «желаемые» сроки. От сроков («желаемых») запрошенных покупателем, сервис расчета может создавать план производства по датам и «свободным» подходящим для выпуска «комплектам оборудования» (для ЖБИ это металлоформы). Этот план связан с заказом и без него не существует.
2.10.7.4.2.В элементе справочника «АУБ Комплекты оборудования» указывается список продукции, для которой он предусмотрен. Для каждой продукции из списка установлена производительность ее выпуска на этом комплекте.
2.10.7.4.3.При расчете плана и сроков, алгоритм минимизирует время хранения и накопления продукции на складе, и создает максимально возможную «свободу для маневра» для выполнения «срочных» заказов.
2.10.7.4.4.При невозможности исполнить сроки покупателя, сервис расчета предложит наиболее близкие возможные сроки для отгрузки. Впоследствии сроки проходят согласование с производством и покупателем, возможно, вводятся новые варианты «желаемых» сроков и делаются новые пересчеты. Формирование плана по заказу и расчет сроков может делаться с учетом «свободного» складского остатка или без него.
2.10.7.4.5.В результате по заказу формируются обязательства предприятия перед покупателем по ассортименту, ценам, объемам и сроками отгрузки. И внутренние обязательства производства по исполнению календарного плана выпуска ЖБИ по заказу. С покупателем устанавливается график оплаты заказа.
2.10.7.4.6.По заказу учитывается резерв по остаткам продукции. Текущий резерв по заказу равен остатку обязательств по отгрузке продукции минус «живой» план этого заказа, т.е. находящейся будущем, «актуальный» остаток плана.
2.10.7.4.7.Свободный остаток продукции на складе - это фактический минус обязательства по отгрузке плюс «живой» план по всем заказам. Если свободный остаток отрицательный, это дефицит. Возможно, дефицит можно устранить, сделав «перепланирование», но если нет «свободных» комплектов оборудования, это не поможет, и нужно заново согласовывать сроки с покупателями, так как выполнить их будет нельзя. Заметим, что изначально «реальный» и сбалансированный по оборудованию план по заказам, простым «игнорированием» выпуска по установленным в нем датам, можно перевести в состояние невосполнимого дефицита.
2.10.7.4.8.Заметим, что покупателям ЖБИ не всегда нужно срочно, но бывает очень важно, что бы точно в срок. Да и выпуск на склад «ходовой» продукции для ЖБИ далеко не всегда подходит.
2.10.7.4.9.Заказ имеет статусы («предварительный, утвержден, отклонен»), после его формирования он обычно находится в статусе «предварительный». Заказ «ждет» от покупателя выполнения «спускового» авансового платежа, предоплаты. Производство в статусе «предварительный» не начинается, но резервирование по заказу уже производится.
2.10.7.4.10.Многие ЖБИ («индивидуальные») делаются только под заказ и при этом они не предусмотрены для складирования и хранения. Начинать выпуск такой продукции нужно после ее оплаты. После получения платежа статус заказа изменяется на «утвержден». Так же «неудобно» и «расточительно» по складским ресурсам накапливать эту продукцию. Максимально эффективно делать и отдавать ее покупателю «точно в срок».
2.10.7.4.11.Если по заказу создан план производства, то по установленным для продукции спецификациям можно сформировать плановое потребление ресурсов на выпуск. Эти данные используются для расчета потребности в сырье и ПФ по датам.
2.10.7.5.Взаиморасчеты по сделкам
Ключевым моментом для обеспечения эффективности оперативного учета на ТехУр является ведение взаиморасчетов по сделкам. Состояние взаиморасчетов по сделке в значительной мере обеспечивает контроль выполнения обязательств по ней.
2.10.7.5.1.Отметим, что в АУБ ТехУр УУ любая поступающая от покупателя оплата может быть «привязана» к одной или нескольким сделкам, и как ранее говорилось (п.2.10.7.1.), в самой сделке отражается график ее оплаты.
2.10.7.5.2.В наработках, реализован функционал автоматизированного заполнения сделок в платежах покупателей при загрузке банковских документов в УУ из РУ. При этом сделка в платеже устанавливается «по умолчанию» и может быть изменена в оплате «вручную» (если система «не угадала»).
2.10.7.5.3.Важно отметить, что в АУБ ТехУр УУ оплаты распределяются по датам графика платежей сделки, а не по датам задолженности покупателя. Платеж распределяется по сделкам «внутри» установленного ФПТ (финансового потока п.2.6.12.6.). Это существенно отличает подход в АУБ от типового функционала в РУ.
2.10.7.5.4.Например, если у покупателя по одной сделке в графике есть не «закрытый» платеж и, допустим, по условиям сделки это предоплата и задолженности нет. При этом по другой сделке уже есть задолженность, но платежи по графику установлены на более поздний срок. То поступивший платеж «по умолчанию» будет установлен на первую сделку, хотя по ней и нет долга (предоплата), несмотря на то, что по второй сделке уже есть задолженность. Если же есть требование покупателя считать, что это платеж именно по второй сделке, несмотря на данные графиков оплат по ним, то «вручную» можно изменить сделку в платеже. Распределение платежей по сделкам делается по данным графиков («по умолчанию») только при загрузке.
2.10.7.5.5.Если на дату платежа у сделки есть не «закрытые» платежи по графику, то она «хочет» оплаты. Поступивший платеж будет распределяться, только на сделки, которые «хотят» оплаты. Если же на дату платежа у сделки по графику нет «открытых» платежей, то она «не хочет» оплаты и поступающие платежи от покупателя «по умолчанию» на нее не распределяются.
2.10.7.5.6.Если в процессе исполнения сделки по ней «все перепуталось» и график платежей уже «ничего не значит», то в заказе можно «отключить» распределение оплаты по графику, при этом в платежах нужно устанавливать эту сделку «вручную».
2.10.7.5.7.Отметим, что правильное ведение взаиморасчетов по сделкам важно для своевременного выявления просрочек в платежах. Данные задолженности по сделкам важны для эффективного управления отношениями с покупателями. Кроме этого состояние взаиморасчетов по сделкам может быть источником данных для системы мотивации, например, менеджеров продаж.
2.10.7.6.Корректировок обязательств
В заказе предусмотрена возможность последующих корректировок обязательств, как по отгрузке продукции, так и по исполнению графика платежей. Но основная функциональная «нагрузка» этих корректировок - это «закрытие», «зачистка» обязательств по заказу.
2.10.7.6.1.В реальности во многих случаях заказ не выполняется на 100%. Особенно это касается весового товара, тогда в обязательствах часто остаются незначительные остатки («хвостики»). Или в процессе исполнения сделки стороны, по взаимному соглашению, скорректировали обязательства «в рабочем порядке».
2.10.7.6.2.В результате, в прошествии времени и исполнения обязательств по заказу в основной части, стороны хотят «закрыть» сделку и обязательства по ней.
2.10.7.6.3.Так как в заказе учитываются обязательства, как по отгрузке, так и по оплате, то необходимо сделать соответствующие корректировки и тех и других обязательств.
2.10.7.6.4.Для корректировки обязательств по отгрузке предусмотрен сервис «закрыть на факт», который корректирует обязательства до величины их фактического исполнения. После этого в учете по сделке обнуляются остатки обязательств по отгрузке.
2.10.7.6.5.Для корректировки в заказе обязательств по оплате предусмотрено два сервиса, это «закрыть на факт» и «закрыть на долг».
2.10.7.6.5.1.Сервис «закрыть на факт» для графика платежей корректирует обязательства до величины фактической оплаты по сделке. Отметим, что сами платежи и долг по сделке никак не изменяются, корректируются только обязательства по платежам. После этого сделка больше «не хочет» оплаты и поступающие платежи от покупателя «по умолчанию» на нее не распределяются. Это поведение будет после «закрытия на факт» вне зависимости от состояния задолженности по сделке. Хотя в «ручную» в поступившем платеже можно установить именно эту сделку.
2.10.7.6.5.2.Сервис «закрыть на долг» корректирует обязательства до величины необходимой для оплаты текущей задолженности по сделке. При этом сделка «хочет» оплаты столько, сколько должен покупатель на момент «закрытия на долг». Поступающие платежи от покупателя «по умолчанию» будут на нее распределяться только на эту сумму, вне зависимости от того какой график платежей изначально был установлен по сделке.
2.10.7.7.Доставка продукции покупателю
Если в сделке предполагается доставка продукции, в заказе могут быть рассчитаны и предъявлены покупателю услуги доставки. В наработке АУБ реализована определенная модель учета и нормирования транспортных услуг.
2.10.7.7.1.Все транспортные услуги (ТУ) сгруппированы по сложившимся на рынке стандартам транспортных услуг (СТУ) и отражены в справочнике «АУБ Стандарты транспортных услуг» (иерархия групп и элементов). Например, «Бортовой автомобиль 20 т, длина 9,0 -13,6 м» (из группы «Доставка ЖБИ»), «Автобетоносмеситель 5 м3» (из группы «Доставка бетона»), «Самосвал грузоподъёмностью до 25т» (из группы «Доставка инертных материалов»).
2.10.7.7.2.Для каждого СТУ настраиваются параметры нормирования стоимости транспортной услуги на единицу расстояния по маршруту, и/или на единицу времени (час) в пути, и/или на единицу времени (час) работы основного оборудования. По каждому варианту определяется минимальное значение и номенклатура для нормирования стоимости ТУ на единицу. Так же в СТУ устанавливается его нормативная грузоподъемность в тоннах или объем в м3.
2.10.7.7.3.В модели учета и нормирования ТУ предусмотрены три варианта ценообразования ТУ: цена за ездку, цена за тонну, цена за час и при необходимости добавляется цена дополнительной работы.
2.10.7.7.4.При расчете стоимости доставки продукции в заказе для каждой ТУ указывается: СТУ, маршрут, расстояние за одну ездку. Выбирается вариант ценообразования ТУ (ездки, тонны, часы), устанавливаются договорная цена и количество ТУ, при этом определяется нормативная и фактическая стоимость ТУ. Для договорной цены может быть предложено нормативное значение цены, рассчитанное от параметров СТУ и введенных данных для услуги.
2.10.7.7.5.Впоследствии по сделке могут быть сопоставлены транспортные услуги - заказанные, фактически оказанные и закупленные (у привлеченных для доставки транспортных компаний).
2.10.8.Дополнение плана по заказам «прогнозным»
Ранее говорилось (п.2.10.5.), что в оперативном планировании производства на ТехУр, для обеспечения полноты плана, данные полученные «по сделкам» нужно дополнять «прогнозными» данными. Это нужно для обеспечения более стабильной загрузки оборудования и трудовых ресурсов предприятия, преодоления «волатильности» планов по заказам.
2.10.8.1.Понятно, что прогнозирование потребности в производстве продукции может строиться на разных принципах, для примера опишем определенный «проектный» вариант решения. Он реализует в оперативном планировании принцип «поддержки заданного минимального свободного остатка продукции». Состав этого остатка отражает продукцию, которую отдел продаж обязуется продать, дополнительно к реализации по заказам, в течение определенного периода. Он должен содержать наиболее «ходовой» товар.
2.10.8.2.На определенный период (месяц) задается регламентный документ ТехУр УУ «Текущий план производства» (ТПП), в котором отражен нормативный свободный остаток продукции, установленный на этот период. Так же в документе рассчитывается плановый график производства продукции в пределах периода, которым «дополняется» план по заказам.
2.10.8.3.Расчет графика производства в ТПП делается только на свободные комплекты оборудования (не занятые по заказам) и в пределах периода. Алгоритм расчета в ТПП аналогичен алгоритму, используемому в заказах при сроках («желаемых») равных текущей дате («срочный заказ»). График рассчитывается до достижения, установленного в ТПП, нормативного свободного остатка продукции, не выходя за пределы периода.
2.10.8.4.Если текущая дата меньше чем начала периода в ТПП (это «будущий» план), то для достижения норматива на свободный остаток учитываются движения выпуска по текущему плану, начиная с даты, следующей за текущей датой, и до конца плана. Это нужно, что бы «стыковать» два актуальных «прогнозных» плана - не закончившийся текущего месяца и еще не начавшийся будущего периода.
2.10.8.5.Отметим, что при планировании по заказам данные «занятости» оборудования, связанные с «прогнозным» планом документа ТПП, игнорируются. Поэтому «условия по занятости» оборудования для расчета в ТПП постоянно изменяются.
2.10.8.6.Предполагается, что специалист, отвечающий за оперативное планирование в производстве, ежедневно (в конце смены) делает перерасчет «текущего плана». Производственное задание на следующую смену делается с учетом «изменившейся» ситуации вызванной новыми заказами. Понятно, что вновь поступившие «крупные» срочные заказы могут изменить всю ситуацию по свободным остаткам и занятости оборудования и потребовать пересчета ТПП.
2.11.Этапы развития автоматизации УУ СЦО в АУБ
Опишем функциональные области (ФО), являющиеся возможными «этапами» развития автоматизации УУ СЦО в АУБ. Определим взаимозависимость этих ФО в процессе внедрения и возможный порядок следования до ЭкУр включительно. Отметим, что в конкретных проектах автоматизации УУ, как состав, так и порядок приведенных областей, может отличаться. Порядок следования ФО в проекте автоматизации УУ не обязательно последовательный, относительно независимые ФО могут автоматизироваться параллельно.
Вероятный состав и порядок следования ФО при развитии автоматизации УУ СЦО, внедрения и доработок функционала АУБ, видится следующим:
-Автоматизация оперативного учета продаж, выпуска и остатков продукции (п.2.11.1.)
-Автоматизация экономического планирования (параллельно) (п.2.11.2.)
-Автоматизация учета объектов имущества (параллельно) (п.2.11.3.)
-Автоматизация учета зарплаты, наличных денежных средств и подотчета (частично параллельно) (п.2.11.4.)
-Автоматизация полного учета денежных средств, взаиморасчетов с покупателями по сделкам, «факта» БДДС (п.2.11.5.)
-Автоматизация оперативного учета закупок, учетных цен и взаиморасчетов (п.2.11.6.)
- Автоматизация склада сырья и материалов, учет расходов и перемещений (п.2.11.7.)
-Автоматизация полного экономического учета «факта» (п.2.11.8.)
2.11.1.Автоматизация оперативного учета продаж, выпуска и остатков продукции
ФО автоматизации ТехУр в составе оперативного управления продажами, отгрузкой, выпуском и складом готовой продукции (ГП).
2.11.1.1.Формируются справочники классов и технической номенклатуры в части продукции, полуфабрикатов (ПФ) и сырья.
2.11.1.2.Разрабатывается справочник спецификаций на продукцию и ПФ. В спецификации вводятся данные расхода материально-технических ресурсов (МТР) на продукцию и ПФ.
2.11.1.3.Разрабатываются и вводятся в систему другие справочники необходимые для автоматизации оперативного управления продажами и производством в зависимости от внедряемого функционала. Например, стандарты транспортных услуг, комплекты оборудования и другие.
2.11.1.4.Вводятся общий и индивидуальные (по контрагентам) прайсы на ГП.
2.11.1.5.Автоматизируется учет сделок продаж (заказы покупателей п.2.10.) и документов реализации без учета складских остатков ГП и взаиморасчетов по сделкам.
2.11.1.6.Инвентаризируются остатки на складах ГП на дату начала ввода всех движений по складу. Автоматизируется учет документов выпуска и складской учет остатков ГП. Отражается расход сырья на производство без учета складских остатков сырья.
2.11.1.7.Отрабатывается интеграция с РУ (п.2.2.) в части документов продажи.
2.11.1.8.Автоматизируется, при необходимости, оперативное планирование производства по сделкам (п.2.10.).
2.11.1.9.При необходимости, делается доработка и внедрение подсистемы управления отгрузкой ГП (например, для добывающей отрасли).
2.11.1.10.Начинается внедрение подсистемы ЦРМ, в части сбора данных по клиентской базе и управления работой менеджеров продаж (без учета взаиморасчетов по сделкам).
2.11.2.Автоматизация экономического планирования (параллельно)
ФО экономического планирования (п.2.6.13.) включает разработку справочников аналитик ЭкУр, структуры бюджетных форм (БФ), ввода плановых движений по сценариям и вывода плановых данных бюджетов в формате настроенных БФ.
2.11.2.1.Экономическое планирование, в силу своей относительной независимости, можно начинать параллельно еще на этапе развития автоматизации ТехУр. Специалисты, занятые во внедрении ФО планирования на ЭкУр, а это вероятно будут сотрудники ФЭО, мало задействованы в развитии автоматизации ТехУр.
2.11.2.2.Отметим, что запуск планирования ЭкУр позволит «наработать» и «отладить» заполнение всех аналитик (справочников) ЭкУр, а это достаточно трудоемкий и длительный процесс. Кроме этого, важно начинать параллельно, т.к. некоторые аналитики ЭкУр задействованы в объектах ТехУр (например, ЛЦО в Зарплате УУ АУБ). Так же параллельное внедрение ФО планирования ЭкУр ускорит освоение сотрудниками ФЭО концепции и функционала АУБ, которые будут им нужны на этапе развития автоматизации «факта» ЭкУр УУ.
2.11.2.3.Разрабатываются и вводятся в систему справочники аналитик необходимые для экономического планирования:
-Справочник «Локальные центры ответственности» (ЛЦО) (организационная структура предприятия (СЦО), центры принятия управленческих решений п.2.6.12.2.);
- Справочник «Финансовые потоки» (ФПТ) (группы движений взаиморасчетов, дебиторской и кредиторской задолженности п.2.6.12.6.);
- Справочник «Сегменты деятельности» (СД) (отдельные направления деятельности, с обособленным учетом доходов и расходов п.2.6.12.3.);
- Справочник «Локальные места затрат» (ЛМЗ) (описывает разделение деятельности СЦО по территориальному признаку п.2.6.12.4.);
- Справочник «Объекты затрат» (ОЗТ) (укрупненная «экономическая» номенклатура, используемая для учета МТР, расчета фактической себестоимости и отражения затрат п.2.6.12.1.);
- Справочник «Потоки затрат» (ПЗТ) (ОС или группы ОС, другие амортизируемые агрегированные активы, резервы под условные активы и обязательства п.2.6.12.5.).
2.11.2.4.Автоматизируется ввод плановых движений по сценариям с использованием документа «АУБ Операция План» (п.2.6.13.6.).
2.11.2.4.1.Ввод плановых движений денежных средств (ДДС) отдельно по ЛЦО.
2.11.2.4.2.Ввод плановых движения отдельно по функциональным бюджетам, например: продаж, производства, закупок, коммерческих расходов, общепроизводственных расходов, расходов на персонал, расходов по налогам, управленческих расходов.
2.11.2.5.Разработка структуры БФ:
-разрабатывается и вводится в систему справочник бюджетов (п.2.6.15.3.1.);
-для каждого бюджета разрабатывается и вводится структура статей бюджета (п.2.6.15.3.2.);
-для каждой созданной статьи бюджетов формируются наборы фильтров (п.2.6.15.3.3.) ее «наполняющих».
2.11.2.5.1.Разработка БФ для бюджета движения денежных средств (БДДС).
2.11.2.5.2.Разработка БФ для бюджета доходов и расходов (БДР) и функциональных бюджетов.
2.11.2.6.Вывод и анализ плановых бюджетов, корректировка введенных плановых движений, доработка структуры аналитик и отладка настроек БФ с использованием отчета «АУБ Обороты по видам движений» (п.2.6.15.4.).
2.11.2.7.Разработка регламента и запуск процесса создания, согласования и корректировки плановых данных. Внедрение экономического планирования в составе разработанных структур бюджетов.
2.11.3.Автоматизация учета объектов имущества (параллельно)
Автоматизация ФО учета объектов имущества (ОИ) на ТехУр (п.2.8.) включает:
определение расположения и назначения использования имущества, разработку его классификации и наборов свойств, полную начальную инвентаризацию ОИ, установку инвентарного номера и материально ответственного лица, отражение состояния ОИ в составе назначенных ему свойств, оценку рыночной стоимости и износа, сопоставление с экономическими (бюджетными) аналитиками.
2.11.3.1.Специалисты, занятые в оперативном учете ОС и других внеоборотных активов не задействованы напрямую в автоматизации УУ связанной с движением оборотных средств. Поэтому в силу относительной независимости внедрение этой ФО возможно параллельно.
2.11.3.2.Делается предварительный анализ (обзор) имущества предприятия по территориям и направлениям деятельности, разрабатывается его классификация (п.2.8.7.1).
2.11.3.2.1.Определяются категории имущества (группы классов) и необходимые классы ОИ, дорабатывается справочник классов.
2.11.3.2.2.Определяются модели одинаковых ОИ используемых на предприятии, дорабатывается справочник технической номенклатуры.
2.11.3.3.Для используемых классов ОИ определяются свойства (п.2.8.7.4), характеризующие как модель имущества, так и объект. Формируются наборы свойств (п.2.8.7.3) определяющих состояние имущества разных классов.
2.11.3.4.Анализируется территориальное размещение и функциональное назначение использование имущества предприятия, разрабатывается справочник «состояния имущества», отражающий это разделение (п.2.8.7.5). Если наработаны экономические аналитики, они устанавливаются в элементах справочника как значения по умолчанию для ОИ.
2.11.3.5.Делается инвентаризация ОИ по территориям и подразделениям предприятия. В систему вводятся ОИ, для них задаются значения назначенных свойств. Каждому ОИ присваивается уникальный инвентарный номер, который физически наносится на объект. По ОИ назначается материально ответственное лицо. ОИ устанавливается в определенное состояние (п.2.8.7.5).
2.11.3.6.Разрабатывается регламент первоначальной оценка стоимости ОИ. По ОИ в системе устанавливается «рыночная» оценка стоимости и износа. Регламентируется и запускается процесс периодической переоценки различных классов ОИ на ТехУр.
2.11.3.7.После наработки экономических аналитик, в учете делаться привязка введенных в систему ОИ к «бюджетным» аналитикам ЭкУр (п.2.8.4.1.).
2.11.4.Автоматизация учета зарплаты, наличных денежных средств и подотчета (частично параллельно)
Состав работ ФО автоматизации учета зарплаты в УУ АУБ (п.2.9.) зависит от подхода к ее учету на предприятии. Он зависит выбора в двух условиях:
-Оформление ЗП («оформленная» и «смешанная») (п.2.9.6.);
-Сложность ЗП («сложная» и «простая») (п.2.9.5.).
2.11.4.1.Параллельное («ускоренное») внедрение ФО в УУ АУБ необходимо только для «смешанной» ЗП, причем если ЗП «сложная», то возможно лишь в базовой части.
2.11.4.1.1.Если ЗП «оформленная» и «простая», задача УУ сводится к «укрупненному переносу» затрат по ЗП из РУ в УУ на ЭкУр (п.2.9.7.1.2.). А это нужно лишь для экономического учета «факта», на завершающем этапе развития автоматизации УУ СЦО в АУБ.
2.11.4.1.2.Кроме этого, если ЗП «сложная», то функционал расчета переменной части зависит от оперативных данных ТехУр УУ (п.2.9.5.3.). Поэтому для развития учета «сложной» ЗП необходимо, что бы другие ФО автоматизации оперативных данных ТехУр УУ были уже внедрены.
Определим основные работы ФО автоматизации учета зарплаты в УУ АУБ в зависимости от подхода к учету ЗП:
2.11.4.2.Доработка и корректировка структуры справочника ЛЦО необходимая для учета зарплаты (параллельно).
2.11.4.3. ЗП «смешанная» (параллельно)
2.11.4.3.1.Обучение и запуск на ТехУр УУ учета наличных денежных средств.
2.11.4.3.2.Ввод начального состояния взаиморасчетов с подотчетными лицами.
2.11.4.3.3.Обучение и запуск ввода авансовых отчетов (только по сумме, временно до п.2.11.6.).
2.11.4.3.4.Разрабатывается и вводится в систему справочник должностей.
2.11.4.3.5.Разработка настройка и заполнение смен и графиков работы.
2.11.4.3.6.Ввод настроек ЗП по каждому работнику.
2.11.4.3.7.Ввод начального состояния взаиморасчетов с работниками.
2.11.4.3.8.Обучение функционалу ЗП в АУБ: основные начисления, дополнительные начисления, удержания из зарплаты, выплата. Запуск учета взаиморасчетов по ЗП для сотрудников в УУ.
2.11.4.4. ЗП «сложная» (не параллельно)
2.11.4.4.1.Разработка функционала расчета переменной части ЗП, отражение в нем зависимости от оперативных данных ТехУр УУ определяемой спецификой управления предприятием.
2.11.4.5. ЗП «сложная» и «оформленная» (не параллельно)
2.11.4.5.1.Разработка функционала передачи в РУ данных расчета переменной части ЗП в УУ и добавления их в документы РУ по ЗП. Для получения в РУ полных начислений «оформленной» ЗП.
2.11.4.6. ЗП «оформленная» и есть учет «факта» затрат на ЭкУр (нужны затраты по ЗП в УУ, делается только для п.2.11.8.) (не параллельно)
2.11.4.6.1.Разработка функционала укрупненного переноса затрат по ЗП из РУ в УУ на ЭкУр и наделению их управленческими аналитиками ЭкУр.
2.11.5.Автоматизация полного учета денежных средств, взаиморасчетов с покупателями по сделкам, «факта» БДДС
2.11.5.1.Автоматизация этой ФО в АУБ предусматривает полный и независимый учет денежных средств (ДС) в УУ. В УУ отражаются все фактические движения денежных средств (ДДС), как на «детальном» ТехУр, так и на ЭкУр. Документы УУ учитывающие ДДС содержат в себе не только все нужные для УУ управленческие аналитики, но и бухгалтерские данные РУ из типовой конфигурации, включая и ссылку на документ РУ - свой «образ» в РУ (если он создан).
2.11.5.2.Отметим, что банковские платежи в РУ отражают фактические ДДС, поэтому они все имеют свои образы в УУ. При этом банковские платежи могут иметь разную интерпретацию в УУ и РУ, поэтому они не агрегируются и соответствуют один к одному.
2.11.5.3.Документы УУ учитывающие оплаты покупателей или выплаты поставщикам могут быть «привязаны» к сделкам. Это нужно для правильного ведения взаиморасчетов по сделкам и контроля сроков платежей.
2.11.5.4.Автоматизации ФО учета ДДС в УУ АУБ решает задачи оперативного (ТехУр) и экономического (ЭкУр) учета.
2.11.5.4.1.Задачи ТехУр - это оперативный учет: остатков по кассам и банковским счетам, взаиморасчетов с сотрудниками по зарплате и подотчету, взаиморасчетов с покупателями и поставщиками по сделкам, прочих взаиморасчетов и платежей.
2.11.5.4.2.Задача ЭкУр - это отражение фактических ДДС по сценарию «Факт основной» проводками по УпрПлСчетов и/или обороты по видам движений бюджетирования в разрезе «экономических» («бюджетных») аналитик ЭкУр.
2.11.5.5.Отметим, что в документах ДДС, реализован специальный «самообучающийся» механизм связей аналитик ТехУр, ЭкУр и бухгалтерских данных из РУ, который обеспечивает заполнение недостающих значений по умолчанию.
2.11.5.6.Так же для внедрения ДДС и взаиморасчетов важно, что в настройках ТехУр АУБ есть возможность:
- устанавливать дату начала управленческого учета остатков на банковском счете;
- устанавливать дату начала упр. учета взаиморасчетов по контрагенту.
По документам ДДС до указанной даты, движения учета соответствующих остатков на ТехУр не делаются.
2.11.5.7.В УУ АУБ различный подход к автоматизации наличных и безналичных ДС.
2.11.5.7.1.Наличные платежи для оперативности получения данных отражаются сначала в УУ АУБ, а в РУ они создаются позже или не создаются (если платеж только управленческий).
2.11.5.7.2.Безналичные платежи сначала импортируются в РУ стандартными средствами (клиент банк), корректируются и проводятся в РУ. Потом обработкой «АУБ Загрузка банка в упр. учет», с использованием механизма связей АУБ, из них делаются соответствующие документы в УУ, с заполненными аналитиками УУ по умолчанию, документы проверяются, корректируются в части данных УУ и проводятся.
Опишем внедрение автоматизации ФО учета ДДС в АУБ:
2.11.5.8.Автоматизация учета наличных ДС в УУ (параллельно)
2.11.5.8.1.Обучение и запуск учета наличных ДС на ТехУр УУ целесообразно делать параллельно в начале внедрения. Это обеспечит оперативность учета наличных платежей, «поддержит» внедрение функционала других ФО, например, расчетов с сотрудниками по «смешанной» ЗП.
2.11.5.8.2.При наработке в параллельной автоматизации экономического планирования (п.2.11.2.) аналитик ЭкУр нужно внедрять их заполнение в документах ДДС для учета наличных. Это позволит с использованием отчетов по ДДС лучше контролировать целевое использование наличных ДС.
2.11.5.8.3.При запуске автоматизации учета сделок продаж (п.2.11.1.5.) нужно сразу внедрять в документах наличных ДС разнесение по сделкам. Это позволит легче контролировать исполнение сроков платежей и упростит впоследствии внедрение учета взаиморасчетов с покупателями по сделкам.
2.11.5.9.Автоматизация учета безналичных ДС в УУ
2.11.5.9.1.Отметим, что количество счетов организаций в СЦО и платежей по ним может быть большим, с дугой стороны, они все уже учитываются в РУ. Внедрение в УУ учета банковских платежей и переход к полному учету ДС в УУ может быть трудоемким. Поэтому имеет смысл начинать внедрение учета безналичных ДС с одновременным запуском «смежного» функционала:
-после начала учета сделок продаж (п.2.11.1.5.), с одновременным запуском учета взаиморасчетов с покупателями по сделкам на ТехУр;
-после наработки аналитики и запуска «плана» ДДС на ЭкУр (п.2.11.2.7.), для одновременного начала учета полного «факта» ДДС на ЭкУр и запуска процесса план-фактного анализа исполнения бюджета БДДС.
2.11.5.9.2.Внедрение импорта из РУ безналичных платежей (обработкой «АУБ Загрузка банка в упр. учет») для учета ДС имеет смысл делать группами по банковским счетам, при этом «включать» учет остатков (п.2.11.5.6.) только для уже «внедренных» счетов. При этом можно контролировать полноту переноса ДДС через сверку входящего и выходящего остатка ДС по счету.
2.11.5.9.3.Внедрение импорта безналичных платежей для учета взаиморасчетов с покупателями по сделкам, нужно делать по группам клиентов, устанавливая в обработке фильтр по клиентам. При этом «включать» учет взаиморасчетов (п.2.11.5.6.) нужно только у этих покупателей.
2.11.5.9.3.1.При «включении» на ТехУр у покупателей учета взаиморасчетов, необходимо установить их начальное состояние, распределив задолженность по сделкам.
2.11.5.9.4.Внедрение импорта безналичных платежей для учета «факта» ДДС на ЭкУр можно делать без «включения» соответствующих настроек: учета остатков на банковском счете, и/или учета взаиморасчетов по контрагенту. Это «снизит» требования к точности данных, например, разнесение платежа по сделкам. Так же будет не обязательна «полнота» импорта платежей по контрагенту (для взаиморасчетов) или банковскому счету (для учета остатков ДС).
2.11.5.10.Таким образом, можно постепенно расширять импорт безналичных платежей:
2.11.5.10.1.Для целей ТехУр, оперативного учета ДС по счетам и учету взаиморасчетов по сделкам. При этом для ТехУр нужно обеспечивать «тщательность» учета «детальных» данных.
2.11.5.10.2.Для целей ЭкУр, экономического учета «факта» ДДС. При этом для ЭкУр важно обеспечить правильность интерпретации ДДС в УУ и указания нужных аналитик ЭкУр, эффективно использовать механизм связей для заполнения по умолчанию аналитик УУ по данным в РУ.
2.11.5.11.После обеспечения полноты импорта безналичных платежей для целей ТехУр будет возможно:
- ведение взаиморасчетов с покупателями по сделкам и контроль сроков оплаты по ним;
- развития системы ЦРМ с учетом данных выполнения обязательств по сделкам;
- развития системы мотивации менеджеров продаж с учетом результатов по сделкам;
- ведение оперативного учета ДС в УУ и оперативного планирования ДДС («платежный календарь»).
2.11.5.12.После обеспечения полноты импорта безналичных платежей для целей ЭкУр будет получен фактический учет ДДС на ЭкУр, в дополнение к автоматизированным ранее плановым данным (п.2.11.2.), и запуск процесса план-фактного анализа исполнения бюджета БДДС.
2.11.6.Автоматизация оперативного учета закупок, учетных цен (УЦ) и взаиморасчетов
2.11.6.1.Автоматизация этой ФО включает нормирование и контроль закупочных цен, расчет на ТехУр по данным спецификаций «сырьевой» нормативной себестоимости продукции и ПФ, ведение УЦ всех МТР, внесение в систему всех закупок МТР, учет оперативных взаиморасчетов с поставщиками и, при необходимости, учет сделок закупки (п.2.10.4.2.).
Определим основные работы автоматизации ФО в АУБ:
2.11.6.2.Дорабатываются справочники классов и технической номенклатуры (ТехНом) в части закупаемых товаров, материалов, услуг, спецодежды, инструмента и других МТР.
2.11.6.2.1.Определяется наличие и перечень «обобщенной» (п.2.7.4.4.1.) ТехНом материалов и услуг, для которой не устанавливается УЦ (п.2.7.4.4.2.) и не учитываются запасы.
2.11.6.3.Первоначальная установка УЦ на ТехУр
2.11.6.3.1.Разрабатывается регламент первоначальной «рыночной» оценки закупаемых и числящихся в запасах МТР и делается установка УЦ для ТехНом (п.2.7.4.).
2.11.6.3.2.Рассчитывается, тестируются и внедряются в работу УЦ себестоимости продукции и ПФ по данным спецификаций (п.2.7.4.2.).
2.11.6.4.Текущая переоценка УЦ на ТехУр
2.11.6.4.1.Разрабатывается регламент текущей переоценки УЦ используемых МТР.
2.11.6.4.2.Запускается процессы:
-актуализации УЦ закупаемых МТР;
-пересчета и согласования изменений УЦ себестоимости продукции на основании спецификаций и УЦ сырья (п.2.7.4.2.).
2.11.6.5.Автоматизируется, при необходимости, учет сделок закупки
2.11.6.5.1.Уточняются требования к функционалу автоматизации сделок закупки с учетом специфики управления закупками в СЦО.
2.11.6.5.2.Дорабатывается функционал учета сделок закупки (п.2.10.4.2.), для учета внутренней потребности в МТР и управления закупками.
2.11.6.6.Распределение оплаты поставщикам по сделкам закупки
2.11.6.6.1.Если в сделках закупки ведется учет графиков платежей поставщикам, то в документе платежа необходимо правильное распределение оплаты по сделкам. Это нужно для возможности контроля выполнения обязательств по оплате в сделке закупки.
2.11.6.6.2.Дорабатывается функционал загрузки банковских документов из РУ в УУ для заполнения «по умолчанию» сделок в оплатах поставщикам с учетом графиков платежей. Сделки в платежах поставщикам устанавливаются при загрузке и впоследствии могут быть скорректированы вручную.
2.11.6.7.Автоматизируется учет документов поступления МТР без учета складских остатков сырья и материалов.
2.11.6.7.1.Уточняются требования к документу поступления МТР и, при необходимости, делается доработка функционала. Проводится обучение, определяется регламент и запускаются процессы:
2.11.6.7.2.Ввод закупок от поставщиков документами поступление МТР.
2.11.6.7.3.Ввод авансовых отчетов (полный учет) через документы поступлением МТР.
2.11.6.7.4.Отрабатывается интеграция с РУ (п.2.2.) документов поступления МТР для закупок.
2.11.6.8.Автоматизируется учет взаиморасчетов с поставщиками.
2.11.6.8.1.Внедрение учета взаиморасчетов с поставщиками, нужно делать по группам, сверив взаиморасчеты и убедившись, что по ним вводятся все платежи и закупки. При этом «включать» учет взаиморасчетов на ТехУр нужно только у этих поставщиков.
2.11.6.8.2.При «включении» на ТехУр у поставщиков учета взаиморасчетов, нужно установить начальное состояние задолженности.
2.11.6.8.3.Если внедрен функционал сделок закупки с учетом обязательств по оплате (графиков платежей), тогда взаиморасчеты с поставщиками ведутся по сделкам.
2.11.7.Автоматизация склада сырья и материалов, учет расходов и перемещений
2.11.7.1.В этой ФО автоматизируется: складской учет остатков сырья и материалов, учет списания в затраты на производство и хозяйственные нужды, учет и нормирование расходов связанных с обслуживанием и ремонтом ОС, учет складских перемещений и, при необходимости, учет трансфертных передач и взаиморасчетов.
2.11.7.2.Отметим, что ранее (п.2.11.6.7.) уже обеспечен ввод документов поступлением МТР, поэтому для обеспечения складского учета остатков сырья и материалов нужны еще движения расхода и перемещения МТР. Так же на дату начала ввода всех движений по складу сырья и материалов необходимо сделать полную инвентаризируются остатков МТР.
Разберем ряд подходов, применяемых в автоматизации этой ФО в АУБ:
2.11.7.3.Расход в производство по норме
2.11.7.3.1.Ранее указывалось (п.2.7.3.3.3.3.), что в практике не всегда возможен «точный» учет расхода сырья на выпуск производственного цикла. Списание тогда производится по «норме» из спецификации.
2.11.7.3.2.Расход по «норме» из спецификации нужно делать непосредственно в документе «АУБ Выпуск продукции», используя сервис расчета нормативной потребности в сырье.
2.11.7.3.3.Накопленное расхождение нормы и факта выявляется по итогам периода, например, месяца, в результате «цеховой» инвентаризации.
2.11.7.4.Расход в затраты по факту
2.11.7.4.1.Фактический расход МТР в затраты отражается: либо со складского остатка документом «АУБ Списание МТР», либо сразу при поступлении документом «АУБ Поступление МТР», например, для услуг.
2.11.7.4.2.Отметим, что в практике часто можно встретить ситуацию, когда «малоценные» расходные материалы, которые не нормируются в спецификациях, отпускаются для хозяйственных нужд со склада «по мере необходимости», без фиксации фактического расхода. При этом на складе не создается значительного запаса, покупка делается так же «по мере необходимости». Такие МТР нужно списывать сразу при поступлении документом «АУБ Поступление МТР», не создавая «виртуальных» остатков на складе. Для таких МТР часто целесообразно использовать «обобщенную» техническую номенклатуру (п.2.7.4.4.2.).
2.11.7.5.Учет расходов на ОС (объекты имущества (ОИ) на ТехУр АУБ)
2.11.7.5.1.Если фактический расход МТР делается для обслуживания или ремонта ОС, то важно в документах расхода (п.2.11.7.4.1.) указывать ОИ, на который списываются МТР. Это позволит использовать функционал контроля расходов на обслуживание и ремонт ОИ (п.2.8.8.).
2.11.7.5.2.При необходимости нормирования расхода МТР на ОИ (ОС), для определенных классов имущества, определяется функционал нужного вида нормирования. Дорабатывается функционал расчета и отражения расхода по норме на ОИ по автоматизируемому виду нормирования. Это позволит сравнивать расходы по норме и по факту на ОИ по видам нормирования (п.2.8.8.5.).
2.11.7.6.Складские перемещения и передачи по трансферту
2.11.7.6.1.В практике часто встречается, что в СЦО учитывается несколько сегментов деятельности (СД) (отдельных направлений деятельности, с обособленным учетом доходов и расходов п.2.6.12.3.). При этом между этими направлениями делаются «внутренние» продажи, отражаемые документом «АУБ Трансферт МТР».
2.11.7.6.2.Складские перемещения (без передачи по трансферту между СД) отражаются документом «АУБ Перемещение МТР».
2.11.7.6.3.Отметим, что на ТехУр одинаковые движения учета МТР для перемещений и передач по трансферту. Различия в движениях для учета МТР возникают только в экономическом учете «факта» на ЭкУр внедряемом позже (п.2.11.8.).
2.11.7.6.4.Однако, уже на этапе автоматизации ТехУр важно различать соответствующие перемещения и передачи отражая их в учете правильными документами. Это нужно, чтобы не было «переучивания» при отражении передач МТР позже (п.2.11.8.).
2.11.7.7.Взаиморасчеты («внутренние») по трансфертным передачам
2.11.7.7.1.Реже встречается, что в СЦО между СД (направлениями деятельности) помимо трансфертных продаж ведутся еще и «внутренние» взаиморасчеты по ним.
2.11.7.7.2.Такая ситуация возникает когда СД имеют оперативную самостоятельность, например, в оплатах поставщикам, выплате ЗП и других денежных расходах. Платежи по трансферту в УУ играют роль передачи денежных средств под оперативное управление от одного СД другому.
2.11.7.7.3.При этом возникает необходимость учета состояния взаиморасчетов между СД. Такая наработка есть в АУБ и документы «АУБ Трансферт МТР», при соответствующей настройке, делают движения по трансфертным взаиморасчетам.
2.11.7.7.4.Трансфертные взаиморасчеты можно учитывать уже на ТехУр в оперативном учете, поэтому при автоматизации этой ФО нужно уточнить их необходимость. Если взаиморасчеты («внутренние») по трансфертным передачам нужны, то при автоматизации этой ФО необходимо их внедрение.
2.11.8.Автоматизация полного экономического учета «факта»
2.11.8.1.Автоматизация ФО позволит определять показатели деятельности СЦО за период в разрезах экономических аналитик, получать фактические данные бюджетов и проводить план-фактный анализ их исполнения в формате настроенных бюджетных форм. Здесь рассчитывается фактическая себестоимость выпускаемой продукции, определяется доходность сегментов деятельности и управленческая прибыль СЦО за месяц, формируется управленческий баланс.
Определим состав задач автоматизации этой ФО:
2.11.8.2.Проверка экономических аналитик
До начала учета «факта» на ЭкУр необходимо провести проверку и доработку справочников основных экономических аналитик. Впоследствии для них будут делаться различные настройки и исправления структуры справочников будут трудоемкими.
2.11.8.2.1.Проверка ОЗТ (Объекты затрат п.2.6.12.1.)
Делается доработка и корректировка справочника ОЗТ для подготовки расчета плановой и фактической себестоимости продукции и ПФ. Для каждого элемента уточняется уровень детализации и настраивается признаки (п.2.6.12.1.2.): наличие количественного учета; наличие учетной цены; наличие нормативной калькуляции.
2.11.8.2.2.Проверка СД (Сегменты деятельности п.2.6.12.3.)
Окончательно определяется и утверждается направления деятельности СЦО.
2.11.8.2.3.Проверка ЛМЗ (Локальные места затрат п.2.6.12.4.)
Окончательно определяется и утверждается территориальная структура деятельности СЦО.
2.11.8.2.4.Проверка ПЗТ (Потоки затрат п.2.6.12.5.)
Делается доработка и корректировка справочника ПЗТ предназначенного для учета крупных ОС или групп ОС и необходимых резервов на ЭкУр.
2.11.8.3.Тестовый режим запуска
Предварительно система запускается в тестовом режиме, в течение которого происходит существенная доработка настроек, калькуляций и учетных цен. Учет в тестовом режиме ведется без проводок по управленческому плану счетов, только оборотами по видам движений (п.2.6.8.).
2.11.8.4.Ввод калькуляций и учетных цен ЭкУр на период «тестовой» эксплуатации
До начала учета «факта» на ЭкУр необходимо установить тестовые учетные цены для плановой (ПланУЦ) (п.2.7.5.2.) и фактической (ФактУЦ) (п.2.7.5.3.) себестоимости. ПланУЦ рассчитываются на основании плановых калькуляций (п.2.6.12.1.5.)продукции и ПФ, поэтому сначала необходимо ввести калькуляции.
2.11.8.4.1.Для ОЗТ продукции и ПФ определяется плановый состав и стоимость поглощенных на производство ресурсов, данные плановых калькуляций вводятся в систему.
2.11.8.4.2.Делается тестовый расчет (п.2.7.5.2.1.) и анализ плановой себестоимости ОЗТ продукции.
2.11.8.4.3.В системе устанавливаются ПланУЦ и ФактУЦ. Временно на «тестовый» период эксплуатации, если не определены данные калькуляций, ПланУЦ могут устанавливаться не по данным расчета, а вручную. На «тестовый» период ФактУЦ устанавливаются, например, по данным ПланУЦ или вручную.
2.11.8.5.Учет факта оборотами на период «тестовой» эксплуатации
2.11.8.5.1.Ввод начальных остатков по регистрам для расчета фактической себестоимости
Для запуска учета на ЭкУр необходима «начальная» установка данных регистра учета запасов МТР в разрезе бюджетных аналитик документом «АУБ Ввод начальных остатков» (п.2.6.14.) в «ограниченной» функциональности (без установки остатков по счетам п.2.6.14.7.).
2.11.8.5.2.Обучение и запуск ввода документов ТехУр с указанием аналитик ЭкУр (п.2.6.4.)
После начала экономического учета «факта» в документах ТехУр необходимо указывать все нужные для ЭкУр аналитики. Сначала документы вводятся в режиме наработки связей ТехУр и ЭкУр (п.2.6.5.), при этом нужно постоянно контролировать правильность заполнения аналитик ЭкУр. Связи нарабатываются автоматически, если заполнение аналитик было неверным, это ошибочное сочетание может предлагаться к заполнению, и должно быть исправлено для правильного авто заполнения.
2.11.8.5.3.Тестовое нормирование ПЗТ (без стоимостной оценки ПЗТ)
Для каждого элемента ПЗТ нужна тестовая настройка (п.2.6.12.5.3.) без использования стоимости ПЗТ, например, используя вид нормы ПЗТ «Нормативное списание на месяц» (п.2.6.12.5.4.). Величина нормы имеет суммовое оценочное (предварительное) значение.
2.11.8.5.4.По итогам месяца тестового периода делается расчет себестоимости. Анализируются результаты учета, дорабатываются данные настроек, калькуляций и учетных цен.
2.11.8.6.Период опытной эксплуатации
В период опытной эксплуатации система впервые запускается в полном функционале (с проводками и остатками по управленческому плану счетов), при этом следует ожидать существенных уточнений и доработки данных
2.11.8.7.Учет балансовый (проводками) в период опытной эксплуатации
2.11.8.7.1.Проверка и уточнение в учете объектов имущества (ОИ) сделанных ранее: стоимостной оценки ОИ (п.2.11.3.6.), привязки ОИ к аналитикам ЭкУр (п.2.11.3.7.). По этим данным устанавливаются суммы остатков по счетам учета ПЗТ для ОС (групп ОС).
2.11.8.7.2.Начальные остатки по счетам вводятся документом «АУБ Ввод начальных остатков» (п.2.6.14.) в полном функционале. В отдельных табличных частях заполняются остатки по различным разделам учета (п.2.6.14.4.), при этом стоимости остатков в документе формируются сервисами с использованием данных ТехУр (п.2.6.14.5.).
2.11.8.7.3.Для ПЗТ учета ОС (групп ОС) делается перенастройка (п.2.6.12.5.3.) с учетом наличия их стоимостной оценки. Например, будет использован вид нормы ПЗТ «Амортизация уменьшаемый остаток» (п.2.6.12.5.4.), а значение нормы равно принятой в УУ норме амортизации для этого ПЗТ (годовой процент возмещения стоимости).
2.11.8.7.4.По итогам месяца периода опытной эксплуатации делается расчет себестоимости и закрытие месяца. Анализируются результаты балансового учета, дорабатываются данные настроек и учетных цен.
2.11.8.8.По окончанию опытной эксплуатации система вводится в промышленную эксплуатацию.
3. Автоматизация оптимизации налогообложения (АОН)
Функционал АОН не является частью УУ и не входит в АУБ, но он часто используется в комплексной автоматизации бизнеса. Требования к функционалу определяются владельцами и руководством предприятия и зависят от специфики управления бизнесом. Кратко опишем его задачи и на примерах рассмотрим возможные подходы к автоматизации.
3.1.Задачи АОН
3.1.1.В процессе налоговой оптимизации, как правило, необходимо дополнять реальные учетные события «виртуальными» чисто оформительскими событиями. При этом в РУ в большом количестве создаются отражающие эти события типовые документы.
3.1.2.Понятно, что создание «виртуальных» событий, предполагает наличие достаточных и точных «управленческих» данных в «оптимизируемых» областях, так как принимать решения на основании данных РУ будет нельзя. Отметим, что обычно это «внутренние» события для предприятия, у них нет «внешних» контрагентов. Поэтому у «виртуальных» оформительских событий и есть «свобода» в их отражении.
3.1.3.Создание таких «виртуальных» документов «вручную» требует больших трудозатрат и приводит к многочисленным ошибкам, специалисты испытывают «психические перегрузки» в работе.
3.1.4.Задача АОН - это автоматизированное создание (генерация) «виртуальных» оформительских событий и соответствующих типовых документов в РУ. Сервисы АОН кардинально снижают трудоемкость налоговой оптимизации, «смягчают» эту работу для исполнителя.
3.2.Подход к функционалу АОН
3.2.1.Используется сервис АОН для создания документов обычно периодически (шагами), по установленному регламенту, например, посуточно. Так же отметим, что АОН - это обычно достаточно сложный сервис, который требует для своей работы большой объем данных различных настроек. Данные настроек АОН могут изменяться от шага к шагу в работе сервиса.
3.2.2.Отметим, что с одной стороны, функционал АОН не является частью УУ и не входит в АУБ, с другой стороны, концепция АУБ настаивает на неизменности типового решения 1С для РУ. Поэтому функционал АОН не нужен ни в составе УУ, ни в составе РУ.
3.2.3.В качестве подхода к реализации сервиса предлагается создание внешних обработок 1С содержащих нужный функционал, а необходимые для его работы данные настроек «упаковываются» в файл XML.
3.2.4.Работа сервиса АОН выглядит примерно так:
3.2.4.1.перед началом работы в сервис «закачиваются» из файла XML сохраненные с прошлого шага данные настроек, при этом возможна их корректировка «вручную»;
3.2.4.2.делается шаг генерации типовых документов в РУ, при этом используются данные настроек и базы данных (типового решения РУ и данные УУ из АУБ). В процессе генерации документов, данные настроек содержащихся в АОН перед шагом, могут изменяться;
3.2.4.3.после окончания работы данные настроек, полученные по результатам сделанного шага, сохраняются в файл XML.
3.3.Примеры сервисов АОН
Рассмотрим ряд примеров, где могут потребоваться сервисы АОН, определим возможный состав функционала.
3.3.1.Генератор материальных потоков
Создание цепочек внутренних виртуальных перепродаж между организациями, используемыми в РУ для оформления деятельности.
3.3.1.1.Например, часто бывает, когда бизнес «оформляется» на несколько организаций, при этом в РУ между этими организациями возникают внутренние операции продажи и покупки, оплаты и получения денежных средств и другие.
3.3.1.2.Допустим, что для бизнеса «удобней», чтобы общий отраженный в РУ доход был «распределен» на несколько собственных организаций учитываемых в РУ в одной базе данных для оформления деятельности. Причем, когда таких «виртуальных» посредников несколько, создаются внутренние цепочки документов покупок и продаж («материальные потоки») связанные с виртуальными перепродажами между организациями.
3.3.1.3.В каждом материальном потоке (МП) есть конечная и начальная организация и один или несколько «посредников». В составе настроек в генераторе задается период (шаг) и фильтр по номенклатуре, в пределах которого делаются виртуальные перепродажи, для всех организаций кроме начальной указывается коэффициент наценки. Так же в настройках для организаций выбираются договора и другие, необходимые для создания документов покупок и продаж данные. В генераторе есть сервис-помощник анализа «внешней» выручки и расчета коэффициентов наценки.
3.3.1.4.Конечная организация «запускает» МП. Для МП она является только покупателем, а ее продажи - это продажи «внешним» реальным контрагентам за указанный период по номенклатуре в соответствии с фильтром.
3.3.1.5.Начальная организация для потока - это только продавец. Обычно эта организация является в РУ производителем продукции, которая перепродается в МП.
3.3.1.6.Генератор создает по коэффициенту наценки для каждой «перепродажи» пару документов (покупки и продажи) по соответствующим организациям. После генерации для выбранного шага все настройки, включая ссылки на созданные цепочки документов, сохраняются в файл XML. Впоследствии они используются для следующего шага генерации. Использование генератора МП для создания «виртуальных» цепочек документов покупок и продаж значительно снижает трудоемкость и позволяет избежать ошибок.
3.3.2.Генератор выпуска
Создание виртуальных документов выпуска продукции в РУ для достижения целевого конечного остатка на указанный период (шаг).
3.3.2.1.Предполагается, что в УУ есть все фактические данные по выпуску продукции, поэтому в РУ можно не дублировать эти данные, формируя выпуск исходя из задач оптимизации. По разным причинам бывает «неудобно» и не нужно отражать в РУ фактический состав выпуска, например, в целях оптимизации остатка продукции числящегося в РУ.
3.3.2.2.Генератор выпуска на основании введенного целевого конечного остатка и данных по движению продукции за период формирует в РУ новый документ выпуска.
3.3.2.3.В составе настроек присутствуют все необходимые данные для создания документа в РУ, например, организация, склад и другие. Также устанавливаются фильтры номенклатуры участвующей в выпуске и связи управленческой и бухгалтерской номенклатуры, если для генерации используются управленческие данные.
3.3.2.4.Основной составляющей настроек генератора является целевой остаток. Он может закачиваться из файла XML предыдущего шага и корректироваться вручную, поддерживая, таким образом, принцип поддержки «утвержденного» остатка продукции в РУ. Но основным способом его создания являются сервисы, поддерживающие определенные «стратегии» при его формировании.
3.3.2.5.Эти стратегии формируют целевой конечный остаток продукции за период, реализуя в выпуске определенный принцип, например:
3.3.2.5.1.устанавливает целевой конечный остаток равный входящему остатку на шаге РУ (поддержка постоянного остатка в РУ);
3.3.2.5.2.устанавливает целевой остаток по данным конечного остатка в УУ (достижение фактического остатка);
3.3.2.5.3.устанавливает выпуск по данным управленческого учета, целевой остаток рассчитывается арифметически (фактический выпуск);
3.3.2.5.4.устанавливает выпуск равный реализации в УУ, целевой остаток рассчитывается арифметически (выпустили - сколько фактически продали).
3.3.2.6.Возможны и какие либо другие «стратегии», создающие более «удобные» остатки в РУ для целей оптимизации. Понятно, что «ручной» расчет данных оптимизации и создание «виртуальных» документов выпуска будет трудоемким и приведет к ошибкам.
3.3.3.Генератор накладных
Создание накладных виртуальной отгрузки в розничные точки на сумму выручки из заданного перечня товара.
3.3.3.1.Допустим, есть сеть из 50 киосков на «вмененке» (ЕНВД). Ежедневно инкассируется с каждой точки сумма выручки, которая регистрируется в РУ. В течение суток делается отгрузка товара в каждую точку, но отражать фактические события отгрузки, допустим, «неудобно» и не нужно.
3.3.3.2.Вместо этого нужно формировать виртуальные отгрузки на заданную целевую сумму выручки. Состав отгрузки нужно формировать, ориентируясь на определенный перечень товара (целевую отгрузку) с ценами и целевыми количествами и объемами мест (например, один товар отгружается штуками, а другой коробками по 20 штук). Накладные отгрузки нужно делать ежедневно в каждый киоск на целевую сумму суточной выручки киоска (отраженной в РУ).
3.3.3.3.Причем, так как ассортимент целевой отгрузки большой, многие товары отгружаются коробками, а суммы выручки с киоска не большие, эту задачу «масштабированием» целевой отгрузки решить нельзя. Накладную в киоск нужно именно «подобрать» ориентируясь на сумму выручки киоска и целевую отгрузку. Сразу заметим, что для бухгалтера создание 50 штук в день таких накладных задача трудная.
3.3.3.4.Генератор накладных, с использованием генератора случайных чисел, «разыгрывает» нужную накладную исходя из целевой отгрузки, целевой выручки и минимальных объемов мест для каждой номенклатуры.
3.3.3.5.В качестве данных настроек в генераторе - целевой перечень с ассортиментом ценами количеством и размером места, так же могут указываться организация и склад. Эти данные относительно постоянные, но при необходимости их можно поменять и сохранить в файл XML.
3.3.3.6.Генератор загружается в 1С, в него считываются данные настроек из файла XML, и далее последовательно вводятся суммы выручки, рассчитывается («разыгрывается») накладная. Если нужно сразу создать в РУ типовой документ «Перемещение товаров», то еще выбираются данные точки и документ автоматизировано создается. Понятно, что при этом будет большой эффект от снижения трудоемкости.
