14.11.2002, 13:02 | #1 |
Участник
|
Использование аналитики vs. возможные проблемы
Вопросы к тем, кто активно использует аналитику.
Есть ли и какая зависимость между использованием аналитики в учёте операций и быстродействием системы (обработка операций, получение отчётов)? Может ли тотальное использование аналитики везде и всюду привести к замедлению работы системы, заметному для конечного пользователя? Или изменение работы системы будет в рамках статистических отклонений? И если обобщить - какие неожиданности/сюрпризы и трудности могут подстерегать начинающих использовать эту замечательную функциональность Аксапты? Заранее признателен всем поделившимся своим опытом. |
|
14.11.2002, 13:15 | #2 |
Участник
|
Есть зависимость.
Но только при работе с бух.итогами. Аксапта создает промежуточные бух.итоги по счетам и по каждой комбинации аналитик. См. таблицу ledgerBalancesDim Поэтому если аналитик очень много, то промежуточные итоги теряют смысл. Надо вернутся к исходному смыслу финансовых аналитик. Финансовые аналитики - средство группировки (классификации) финансовых проводок. Не больше и не меньше. Классификация, состоящая из сотен элементов... надо хорошо обосновать такое решение... Поэтому вешать договора, клиентов, поставщиков на финансовую аналитику не стоит. |
|
15.11.2002, 16:57 | #3 |
Участник
|
Посмотрел я таблицу LedgerBalancesDim.
В ней делается по одной записи для каждого имеющего место быть уникального набора параметров: - номер бухгалтерского счёта; - отчётный период; - код аналитики (по умолчанию, 3 разных типа - 3 поля в таблице). Отчётный период обычно равен месяцу. Исходя из этого, по моему мнению, таблица будет "пухнуть" медленнее, чем оперативные таблицы (такие, как проводки по номенклатуре). Насколько я понял финансовую аналитику - она именно предназначена для детализации данных по оборотам по бухгалтерским счетам. Причём, в системе зашиты возможности детализации именно по клиентам, поставщикам, номенклатурам, операциям и т.д. Естественно, что за это придётся заплатить дополнительной кучей данных в базе. Так почему же не стоит этим воспользоваться, конечно же в рамках некоторой общей концепции, чтобы не запутаться в дополнительной информации? |
|
15.11.2002, 17:12 | #4 |
Шаман форума
|
То есть Вам сквозная аналитика не нравится или аналитика модулей?
|
|
15.11.2002, 19:14 | #5 |
Участник
|
Сквозная аналитика не нравится. При ней план счетов станет нечитаемым. Да и появится потребность его изменять, чего очень бы не хотелось.
Аналитика модулей нравится, но в рассматриваемом случае ею нельзя будет воспользоваться. Проводки будут формироваться только по Главной Книге. Соответственно, хочется получить механизм, позволяющий фиксировать дополнительную информацию с учётом указанных выше ограничений. |
|
15.11.2002, 20:03 | #6 |
Участник
|
Вопрос уже FAQовый.
Давно хочу написать статью да руки не доходят. Тезисы: 1. Как строится фин.учет на западе 1.1. Финансист продумывает главные фин.отчеты - баланс (BS) и отчет о прибылях и убытках (PL). Главная цель этой работы - задать возможные варианты анализа (Аналог в OLAP создать измерения и ресурсы). Главная цель анализа и отчетности - по возможности без искажений отразить реальную жизнь. 1.2. Правильный финансист еще продумывает CashFlow и добавляет соответствующие разделы в BS и PL 1.3. Хороший финансист продумывает структуру бюджетов и продумывает увязку бюджетов и BS с PL 1.4. Замечательный финансист продумывает структуру комментариев к отчетам и соответствующим образом корректирует разделы BS и PL. 1.5 После чего просто нумерует строчки BS и PL и получает план счетов. В результате западному финансисту априори достаточно для финансового анализа плана счетов! Аналитика для западного плана является дополнительным инструментом для детализации. Но ни в коем случае не обязательной для построения фин.отчетов. Аналитика удобный дополнительный инструмент. Для реализации такого подхода построены западные программы. (Заметим, что финансиста в этом случае будет интересовать в основном контроль за правильностью и корректностью ввода. То, что он задумал должно исполняться в точности и в срок) 2. Как строится фин. учет у нас 2.1. Берется типовой план счетов 2.2. Начинается работа по этому плану счетов 2.3. По мере необходимости вводятся субсчета для текущей работы. 2.4. Наступает время составления отчетности. 2.5. Главбух садится и думает как из того, что навводили на разные субсчета составить предписанную отчетность. Главный критерий при составлении отчетности - заплатить поменьше налогов. Поскольку наваяли проводок по разному и от души, то возникает задача N1 - исправить проводки задним числом. (Какой контроль? Главная задача выйти на меньшие налоги) Затем возникает задача анализа того, что получилось. Тут уже просто плана счетов не хватает. Нужно анализировать с точностью почти до проводки. Тут без дополнительных разрезов не обойтись. Эти дополнительные разрезы должны быть различными. Систему в них усмотреть сложно. Обычно здесь появляется номенклатура на 60 и 19 счетах, или нечто экзотическое, типа сотрудников на 10 или материалов на 71 )) Из различий в подходах и все следствия, связанные с аналитикой Следующая статья должна быть - как получать оборотно сальдовую ведомость по 62 счету в разрезе контрагентов в Аксапте. В двух словах - берем две таблицы LedgerTrans и CustTrans, join по Voucher, group by CustAccount. Это стандартный способ. Есть даже стандартный отчет по расхождению. Есть стандартные административные регламентные процедуры по поддержанию непротиворечивости.... И т.п. Такой подход позволяет получать отчеты не только по наперед заданной аналитике, но и в любых разрезах. (Кстати, OLAP здесь очень в тему) Есть и ограничения. Например налоги в странах европы начисляются на весь документ, а не на строки документа. Для США ввели дополнительную функциональность. В результате не так просто правильно связать некоторые таблицы. Так что проблемы есть. Однако, связь нескольких таблиц по Voucher дает просто фантастические результаты. Надеюсь, что для размышлений достаточно. Эх, где бы время взять. Много... |
|
|
За это сообщение автора поблагодарили: sukhanchik (4), alex55 (1). |
18.11.2002, 19:00 | #7 |
Участник
|
По поводу статьи 1.
На сколько нам представляется , мы как раз и следуем принятому на Западе подходу. Только нагрузка на аналитику будет немного больше всвязи с комментарием к статье 2. По поводу статьи 2. В общем случае она была бы очень нужной. Но в рассматриваемом примере (см. моё предыдущее сообщение) приходится исходить из того, что таблицы CustTrans, VendTrans и иже с ними пусты.... Вот и остаётся одна надежда - на аналитику. |
|
18.11.2002, 19:33 | #8 |
Шаман форума
|
Почему план счетов станет нечитаемым?
Просто не надо дублировать аналитику модулей сквозной аналитикой. Просто не могу себе представить ситуацию, когда Акзапта запускается только с функциональностью Главной книги. Но если это так, тогда действительно нужна аналитика а-ля 1С, то есть фактически набор субсчетов. |
|
18.11.2002, 20:09 | #9 |
Member
|
Цитата:
Изначально опубликовано mazzy
Надо вернутся к исходному смыслу финансовых аналитик. Финансовые аналитики - средство группировки (классификации) финансовых проводок. Не больше и не меньше. Классификация, состоящая из сотен элементов... надо хорошо обосновать такое решение... Поэтому вешать договора, клиентов, поставщиков на финансовую аналитику не стоит. Цитата:
Изначально опубликовано Boris
Насколько я понял финансовую аналитику - она именно предназначена для детализации данных по оборотам по бухгалтерским счетам. Причём, в системе зашиты возможности детализации именно по клиентам, поставщикам, номенклатурам, операциям и т.д. Естественно, что за это придётся заплатить дополнительной кучей данных в базе. Так почему же не стоит этим воспользоваться, конечно же в рамках некоторой общей концепции, чтобы не запутаться в дополнительной информации? Цитата:
Изначально опубликовано mazzy
...Поэтому если аналитик очень много, то промежуточные итоги теряют смысл... 2. Это утверждение может быть верным только теоретически, если одной из аналитик будет дата и время, либо что-то похожее на складсую аналитику серийный номер (однозначно идентифицирующую бухгалтерскую проводку). В противном случае проводки, как правило, будут агрегироваться. В самом же худшем случае количество записей в ledgerBalancesDim не превысит количество записей в LedgerTrans. Судя по тому, что еще существует ledgerBalances, разработчики не очень беспокоились об экономии места. Скорее их интересовала скорость отработки аналитических запросов. И они исходили из предпосылки, что проводок в течение финансового периода будет очень много. Иначе бы они просто не сделали такие таблицы. Я так думаю. Цитата:
Изначально опубликовано mazzy
...Надо вернутся к исходному смыслу финансовых аналитик. Финансовые аналитики - средство группировки (классификации) финансовых проводок. Не больше и не меньше... Насчет того, что аналитики не должны использоваться для финансового учета и отчетности, - согласен на 100%. Цитата:
Изначально опубликовано mazzy
...Поэтому вешать договора, клиентов, поставщиков на финансовую аналитику не стоит. Так что нужно смотреть на каждую конкретную ситуацию и... думать. И еще про аналитики. Аналитики имеют тенденцию проставляться далеко не на всех счетах плана счетов. На некоторых проставляется одна, на некоторых две и более. Но на большинстве счетов их не будет. А это еще один аргумент в пользу того, что принцип агрегации будет работать. |
|
19.11.2002, 11:48 | #10 |
Участник
|
Спасибо.
Надо подумать. |
|
21.11.2002, 10:05 | #11 |
Участник
|
Возможно ли в Аксапте в качестве аналитики использовать справочник, например по сч.62 справочник Клиентов? Или это возможно настроить только субсчетами?
|
|
21.11.2002, 11:04 | #12 |
Участник
|
Цитата:
Возможно ли в Аксапте в качестве аналитики использовать справочник, например по сч.62 справочник Клиентов? Или это возможно настроить только субсчетами?
1. Эта настройка будет работать для ВСЕХ счетов? А нужна ли Вам такая аналитика, например, на 70 счете? Хотя, в принципе, это нестрашно. 2. Эту связь можно всегда восстановить по ссылкам, как уже mazzy рассказывал, не вводя новой аналитики. И зачем тогда лишняя аналитика? Цитата:
Поставщиков - однозначно не стоит. Клиентов - можно, но только в агрегированном виде, например, в виде регионов сбыта (под бюджетирование).
Цитата:
Договора - зависит от их количества. Если договоров 10000 и месяц - то нет.
|
|
21.11.2002, 11:22 | #13 |
Шаман форума
|
Сущность "договоры" появилась в 4 сервиспаке.
|
|
21.11.2002, 11:29 | #14 |
Участник
|
Спасибо за информацию, будем ждать официального релиза
|
|
21.11.2002, 13:24 | #15 |
Шаман форума
|
Так он вроде был....
|
|
21.11.2002, 14:05 | #16 |
Участник
|
До нас пока не дошел
|
|
21.11.2002, 17:30 | #17 |
Шаман форума
|
Месяца 2 уже, не меньше. Самолет хорошо,а олени лучше.
|
|
22.11.2002, 11:23 | #18 |
Участник
|
Цитата:
Изначально опубликовано Михаил Андреев
А вот для бюджетирования, увы, придется, наверное, аналитику использовать. Есть прогноз продаж, закупок и складских запасов. Детальное планирование продаж по клиентам лучше вести там. А в бюджет передавать общую сумму для финансового бюджетирования. |
|
22.11.2002, 18:56 | #19 |
Участник
|
Изначально опубликовано mazzy
...Надо вернутся к исходному смыслу финансовых аналитик. Финансовые аналитики - средство группировки (классификации) финансовых проводок. Не больше и не меньше... Изначально опубликовано glibs: Аналитика "центр затрат". Что же она обобщает? Она детализирует обороты по счетам затрат (административных расходов, затрат на сбыт, пр.). Возможно, и по счетам доходов. Противопоставление этих двух подходов, с моей точки зрения, не очень оправдано. Введенная аналитика группирует проводки и детализирует обороты по счетам. И то, и другое правильно. Точно также оглавление книги группирует строки текста и детализирует содержание книги. Изначально опубликовано glibs: Насчет того, что аналитики не должны использоваться для финансового учета и отчетности, - согласен на 100%. Неужели все так однозначно, и не остается даже 1% на сомнения? Мне больше нравиться другое Ваше утверждение: Изначально опубликовано glibs: Так что нужно смотреть на каждую конкретную ситуацию и... думать. Возьмем несколько примеров. В форме №2 бухгалтерской отчетности предполагается расшифровка выручки по видам деятельности, причем выручка по данному виду подлежит отражению отдельно в случае превышения 5% от оборота. Мне кажется, что не всегда удобно отражать это только через счета. В налоговом учете есть нормируемые для целей налогообложения затраты, и понятно, что регистры учета должны содержать раздельный учет этих затрат. Неужели всегда это нужно делать через счета? В финансовом анализе при расчете оборачиваемости представьте себе ситуацию, когда один и тот же материал у Вас используется как товар, и как сырье для производства, причем заранее не известно, что будет продано, а что переработано. Можно, конечно, расписать систему проводок по счетам, но, может быть, можно использовать и аналитику? Мне представляется, что ряде случаев это. может быть удобно
__________________
Сергей |
|
23.11.2002, 16:18 | #20 |
SAP
|
Re: Использование аналитики vs. возможные проблемы
Привет,
Цитата:
Изначально опубликовано Boris
Есть ли и какая зависимость между использованием аналитики в учёте операций и быстродействием системы (обработка операций, получение отчётов)? Может ли тотальное использование аналитики везде и всюду привести к замедлению работы системы, заметному для конечного пользователя? Цитата:
Изначально опубликовано Boris
И если обобщить - какие неожиданности/сюрпризы и трудности могут подстерегать начинающих использовать эту замечательную функциональность Аксапты? И самое главное - аналитика как элемент управленческого учета достаточно часто вступает в противоречие с российскими правилами формирования проводок по бухгалтерскому учету, например, корреспонденцией. Самый показательный пример: попытка откорреспондировать проводки, полученные после пересчета себестоимости товаров в конце периода по методике отличной от средней, когда в проводках задействованы пара-тройка аналитических измерений. С уважением. |
|
Теги |
аналитика, аналитические отчеты, как правильно, развернутое сальдо, финансовый учет, финансовая аналитика |
|
Опции темы | Поиск в этой теме |
Опции просмотра | |
|