плюсы и минусы изменений в работе с фин.аналитиками в AX 2012

[gl00mie]

Цитата:

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

Да, будут проблемы переноса существующего функционала.

Причем очень нефиговые: если, к примеру, раньше можно было для заполнения просто записать значение в поле, то теперь придется выбирать текущую запись, менять ее и дергать код наподобие InventDim::findOrCreate().

Цитата:

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

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

а еще в куче мест кода появится что-то вроде InventDimParm

Цитата:

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

Но зато теперь можно будет взять и добавить аналитику Клиент / Проект / Договор / Юрлицо - ссылаяся напрямую на справочник

С одной стороны, это здорово - иметь такую возможность чисто технически, но с другой, польза от дополнительных аналитик появляется лишь тогда, когда их кто-то заполняет. Кто будет заполнять все эти "субконто"? Если автоматом (по каким-нить заказам это вроде не сложно), это один вариант, хотя и он мне кажется нетривиальным в общем случае. Если же руками, то тут начинается веселуха, как с теми же ГТД: пользователи где-нить ошиблись, затем фарш ндцать раз провернули, а когда пару-тройку недель спустя косяк обнаружится (причем по косвенным признакам, и надо будет еще раскопать, из-за чего данные не сходятся), то прибегут и скажут, мол, надо исправить, а то нам отчетность сдавать, и волшебное слово - "быстро!"
В общем случае (на примере тех же ГТД) можно побробовать перебить данные прямо в LedgerDim в надежде, что новые комбинации аналитик там еще не встречаются, затем надо будет по перекрестным ссылкам найти еще те таблицы, где чихать хотели на подобные заморочки и хранят нужные коды аналитик по значению, а не по LedgerDimId (как те же фактуры применительно к ГТД). Но вот если по каким-то причинам комбинации аналитик, на которые надо переправить данные, уже есть, тады - ой! Потому что получается, что для исправления данных надо будет либо вообще весь фарш обратно проворачивать и потом закатывать все как надо, либо надо будет во всех связанных проводках как-то хитро перебивать LedgerDimId, а это уже на два порядка более трудоемкая и опасная с точки зрения сохранения целостности данных задача.
Я уже не говорю про такие мелочи при добавлении своих "субконто", как проверки допустимости их комбинаций (чтоб субконто-договор относился к тому же субконто-контрагенту или чтоб срок его действия покрывал дату проводки). Да и вообще, у меня идеи с навешиванием кучи фин.аналитик ассоциируются в первую очередь с желанием бухов строить оборотки по счетам ГК в самых разнообразных разрезах, хотя, может, где-то это на самом деле нужно. К примеру, была какая-то законодательная замута с тем, чтобы ограничить макс. сумму наличных оплат по одному договору. Если бы сделать договор фин.аналитикой и корректно ее заполнять, то технически реализовать это было бы проще простого.

[pitersky]

Цитата:

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

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

точно-точно. все 1С-ные субконто есть в модульных проводках, незачем их в ГК пихать

[TasmanianDevil]

Цитата:

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

точно-точно. все 1С-ные субконто есть в модульных проводках, незачем их в ГК пихать

И сальды ГК по их разрезам считать с начала времен ?

[sukhanchik]

Цитата:

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

Причем очень нефиговые

Цитата:

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

а еще в куче мест кода появится что-то вроде InventDimParm

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

Цитата:

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

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

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

Другое дело - что в простом случае - наличие большого количества аналитик наводит на мысль об их избыточности. Но... опять-таки - кому жалко лишнего поля? Стоимость жестких дисков нонче ничтожно мала по сравнению со стоимостью памяти / процессоров и т.д. Поэтому даже если СУБД раздуется в 2 раза (чему 100% не бывать) - то расходы на ее обслуживание с лихвой покроются экономией на прочих железках и экономией времени пользователей отчетов.

[Pustik]

Цитата:

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

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

Согласен. Исправлять конструкцию с InventDimId(LedgerDimId) на порядок (а то и два) сложнее чем Dimension.