DAX 2009: Ledger Table открывается медленно

[Qaz Qwerty]

Странное дело, в целом все нормально шевелится, но вот конкретно форма плана счетов открывается минуту, записей не много (400). Что проверить посоветуете, коллеги?

[EVGL]

Проверить настройки баланса, который справа показывается?

[Qaz Qwerty]

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

[EVGL]

1) Первый совет, наверное, банален, но все же: баланс показывать с 01.01 текущего года, т.е. не ставить дату "от" далеко в прошлое. К сожалению, в стандарте есть извращение, что при показе баланса "от"-"до" в него не включаются открывающие проводки. С этим боремся парой исправлений в определенных местах.

2) Если первый совет слишком банален, придется идти по тернистому пути проверки длинных запросов, добавления индексов, тонких настроек сервера БД.

[Qaz Qwerty]

да, похоже так оно и есть... с начала фискального года не включает начальные остатки. вот ведь... спасибо!

[mazzy]

Цитата:

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

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

это скорее не извращение, а неочевидность.

есть поставить дату фин.года, то будет показано сальдо (открывающие + обычные проводки)
если поставить "от-до", то будет показан оборот (обычные проводки).

и, по-моему, так сделано специально.
хоть и чертовски неочевидно.

в форме настройки плана счетов достаточно поставить какую-нибудь дату финансового года.

[EVGL]

Да, работать с этой "неочевидностью" тяжело. Мои клиенты в Польше, в частности, наотрез отказались

Я долго пытался понять, почему так сделано и зачем, но не смог найди ни одной разумной причины. Даже если показывать проводки с декабря по январь, открывющие проводки сократятся с закрывающими, т.е. можно показывать все. Кто-то обкурился, когда писал в Microsoft спецификацию 15 лет назад.

[mazzy]

Цитата:

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

Я долго пытался понять, почему так сделано и зачем, но не смог найди ни одной разумной причины. Даже если показывать проводки с декабря по январь, открывющие проводки сократятся с закрывающими, т.е. можно показывать все. Кто-то обкурился, когда писал в Microsoft спецификацию 15 лет назад.

А скорее всего - историческое развитие.
скорее всего изначально была одна дата - по ней определялся фин.год (включая открывающие сальдо)

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

[Ivanhoe]

Мне такой подход нравится =). При должном объяснении пользователям именно так и работаем - смотрим либо оборот, либо сальдо.

[glibs]

Эта "неочевидность" очень полезна. И никто там не обкурился. В то время в Аксапте еще серьезно занимались развитием функционала.

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

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

Так что не нужно агитировать. Есть два способа расчета. Оба полезные. Один из них быстрее.

По-моему сейчас просто народ разленился учить функционал. Привыкли все по коду рыскать да быстро что-то править. Нужно просто знать особенности той или иной функциональности.

[petr]

На всякий случай напомню (надеюсь вы и так знали)

Делайте периодически пересчет сальдо по периодам.

[glibs]

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

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

[EVGL]

Цитата:

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

По-моему сейчас просто народ разленился учить функционал. Привыкли все по коду рыскать да быстро что-то править. Нужно просто знать особенности той или иной функциональности.

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

[glibs]

Такое требование бухгалтера правильным будет реализовывать как доработку еще одного режима просмотра сальдо (в настройках сальдо добавить третью опцию "Сальдо на дату"), а не как изменение стандартного алгоритма одной из существующих опций.

[EVGL]

Цитата:

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

Такое требование бухгалтера правильным будет реализовывать как доработку еще одного режима просмотра сальдо (в настройках сальдо добавить третью опцию "Сальдо на дату"), а не как изменение стандартного алгоритма одной из существующих опций.

Согласен! Не хватает параметра.

[BOAL]

Не удержался.. офтопик

Вот же время и клиентская работа влияет на людей (разработчиков)!
Когда-то EVGL ходил по офису и бил линейкой по рукам тех, кто даже подумывал че-то свое написать в LedgerT*
Ибо "стандарт и так хорош, объясните им (юзерям), как вернее жить"
И тут о чудо!
"Можно понять."

Просто улыбнуло
Тк я сам иногда с теплотой вспоминаю ту линейку (и даже завел свою ) Но применяю ее для других, но похожих воспитательных целей (приоритеты стандарта давно спасовали перед сроками и удовлетворенным клиентом)


Мы для себя (для сейлз дел) даже терминологию ввели на базе табличек GAP\FIT, которые в тендерах применяют и делят системы по критерию кастомизация на настройка\разработка
Так вот - если АХ меряют так же, то там почти все станет разработкой, тк в АОТ нужно лезть, чтоб столбик добавить или перенести. И по гап\фиту будет фигня на фоне других систем.
Потому - мелкий кодинг - это настройка под требования юзера
Уж визуальное таскание контролек в АОТ точно.

[EVGL]

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

[Qaz Qwerty]

Цитата:

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

По-моему сейчас просто народ разленился учить функционал. Привыкли все по коду рыскать да быстро что-то править. Нужно просто знать особенности той или иной функциональности.

оффтопик: Есть хорошие книги, описания по функциональности? Все же изучение функциональности системы не должно превращаться в гуруизм (то есть "доступно только с годами") и устно-письменное творчество участников конференций, не должно приводить к копанию в коде, чтобы понять логику, и вроде должно занимать меньше времени, чем изучение библии. Впрочем все уже 1000 раз сказано, не интересно.

[glibs]

"Хочешь сделать — найдешь способ, не хочешь — найдешь причину".

"Без труда не вытащишь и рыбку из пруда".

Когда что-нибудь изучать было легко? Это труд (умственный). А иначе не выучишь. Сам поцесс познания развивает (одно дело прочитать — другое проверить в системе самому — запоминается гораздо лучше). Вы книжку под подушку хотите положить чтобы знания в голову перетекли?

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

[fed]

Хочу заметить, что в системе есть достаточно много функциональности (в том числе, написанной и отцами-основателями в Дамгаардовские времена), которая не несет никакой фундаментальной ценности и не всегда была так уж хорошо продумана. Соответственно - я могу понять смысл разбирательства в работе сводного планирования или закрытия склада или налогового модуля. Но я не вижу смысла каждый раз копаться в коде или методом проб и ошибок изучать каждую галочку и странность в системе. Как говорил один мой приятель:"Вот сидишь-сидишь, разбираешься-разбираешься, а потом все равно оказывается что оно никуда не годиться и проще свое написать, чем стандарт подправить".
Знание стандартной функциональности - это не цель, а средство. И я не вижу смысла прикладывать какие-то экстраординарные усилия для того чтобы выучить всю функциональность. Если ты некоторые базовые вещи по архитектуре системы понимаешь (и достигается это понимание ТОЛЬКО большим практическим опытом внедрений, а не экспериментами с галочками), то при попытке сделать свою функциональность, ты, скорее всего, полезешь в правильное место в коде и обнаружишь там что нужная функциональность уже написана, просто она зависит от галочки, которую ты пока не знаешь.

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