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

[gl00mie]

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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