Изменение аналитики

[gaenar]

Уважаемые профессионалы!

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

Есть ли какое-нибудь другое решение этого вопроса (хотя бы на уровне идеи)?

P.S. Я вижу только два варианта кроме описанного выше:
1) вести УУ в другой компании отдельно, со всеми вытекающими
2) корректировать только Trans'ы (минус сразу - можно навернуться на логике, работающей по аналитике, ну и фактуры с накладными)

[slava09]

Цитата:

Сообщение от gaenar

В аксапте заложен серьёзный инструмент - аналитика (Dimensions).

Он поэтому и серьезный, потому что нельзя менять задним числом.

1) А что Вам даст ведение УУ в другой компании? Там тоже нельзя будет менять задним числом.
2) Если уж очень хочется корректировать задним числом, то пишите модификации корректировки аналитики в Trans' ах и в других объектах, хотя это ОЧЕНЬ порочная практика!
3) И всетаки не стоит заморачиватся не с 1) не с 2). Лучше разберитесь хорошо какие операции придется корректировать и пропишите четкие инструкции для каждого случая. Обучите пользователей и установите жесткий административный контроль за этим делом.

[gaenar]

Цитата:

Сообщение от slava09

1) А что Вам даст ведение УУ в другой компании? Там тоже нельзя будет менять задним числом.

Я имел в виду очень простой случай, когда LedgerTrans выгружается в другую компанию и там с ним делается всё, что и 1Су не снилось.

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

Пока решаем "порочным" путём - коррекция аналитики всех проводок, относящихся к этой операции Никаких проблем, но возмещение НДС не скорректировать. Проводки 68 19 кладутся общими суммами без учета аналитики. На результат важных отчётов практически не влияет, но жизнь портит. Тем более, такое решение нельзя транслировать на другие бизнесы, а это 100% минус.

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

С уважением, Селихов Артём

[slava09]

Цитата:

Сообщение от gaenar

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

Ну смотрите сами:платежку разнесли на отдел потому что думали, что материал идет отделу №1. Потом выяснилось, что материал нужен был не отделу №1 а отделу №2.
Почему возникла такая ситуация? Кто заказывал материал отделу №1 который там и не нужен? Почему вдруг отделу №2 подходит материал предназначенный для отдела №1? В дальнейшем заказывать материал на отдел №1, или сразу заказывать его на отдел №2 или заказывать на оба отдела?
Понимаете? Возникает куча полезных вопросов в конце периода, но если вы не имеете истории то эти вопросы и не возникнут.

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

Артем, честное слово, не закладывайтесь на такие модификации системы. Купите лучше 1С7.7 и настройте экспорт данных туда и там сводите бухгалтерию - это будет дешевле и эффективне. Будете править, перепроводить, получать извращенские отчеты для налоговой и т.д.

[gaenar]

Цитата:

Сообщение от slava09

Ну смотрите сами:платежку разнесли на отдел потому что думали, что материал идет отделу №1. Потом выяснилось, что материал нужен был не отделу №1 а отделу №2.
Почему возникла такая ситуация? Кто заказывал материал отделу №1 который там и не нужен? Почему вдруг отделу №2 подходит материал предназначенный для отдела №1? В дальнейшем заказывать материал на отдел №1, или сразу заказывать его на отдел №2 или заказывать на оба отдела?
Понимаете? Возникает куча полезных вопросов в конце периода, но если вы не имеете истории то эти вопросы и не возникнут.

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

Про 1С - это решение просто классика на века

2 glibs
Всё правильно, нужно добиваться точности и конечности. Но не всегда это удаётся сделать сразу.

[slava09]

Цитата:

Сообщение от gaenar

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

Про 1С - это решение просто классика на века

Издеваетесь?

[slava09]

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

[glibs]

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

Например, зачем в платеже указывать отдел?

[gaenar]

Эти две фразы контекстно не связаны. Идёт внедрение дополнительного функционала в Аксапте. А решение "для бухгалтера" - поставить 1С сбоку, вот это классика.

P.S. а иногда хочется... сказать, хотите легко и быстро - вот вам 1С в коробочке. Но не дождутся.

[slava09]

Цитата:

Сообщение от gaenar

P.S. а иногда хочется... сказать, хотите легко и быстро - вот вам 1С в коробочке. Но не дождутся.

Ну тогда подумайте над вариантом: автоматизировать сторнировку. Или спросите у glibs чтобы конкретнее объяснил свою мысль.

[glibs]

А что тут объяснять?

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

Отдел или ЦФО, в общем случае, становится известным после того, как что-то закупленное будет списано на расходы периода.

Самый простой вариант — переходить с кассового метода финансового планирования и анализа на метод начисления.

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

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

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

Фактического потребителя не помогут определить даже сопоставления по клиентам и поставщикам. Наиболее простой вариант — закупать на некоторое "снабженческое" подразделение, а по факту потребления перераспределять уже на конкретный отдел в отчете. Но тогда некоторое время суммы оплаты в отчете будут отображаться как нераспределенные.

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

Примерно вот так.

[gaenar]

Спасибо, glibs, спасибо Слава.

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