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

[sukhanchik]

Выделено из Предварительные выводы о переходе с AX2009 на AX2012
по просьбе участников ветки

С финаналитиками (то, что они будут как складские, плюс счет ГК будет являться одной из аналитик) - тоже изменение поддерживаю.
Да, будут проблемы переноса существующего функционала.
Да, надо будет постоянно в запросах "приджойнивать" табличку комбинаций.
Да, вопрос производительности - остается открытым (впрочем, вопрос производительности открыт по отношению ко всей системе)
Но зато теперь можно будет в качестве аналитики использовать конкретный справочник. Не заводить свой искусственный и заниматься его синхронизацией, а также ограничивать себя в добавлении полей, понимая, что это затронет сразу всю табличку Dimensions.
Т.е. теперь можно будет взять и добавить аналитику Клиент / Проект / Договор / Юрлицо - ссылаяся напрямую на справочник (а-ля субконто в 1С). Также как это сделано в складских аналитиках.

[mazzy]

см. также
10 финансовых аналитик. Проблема решена в Dynamics Ax 2012

[gl00mie]

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

[pitersky]

Цитата:

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

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

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

[sukhanchik]

Цитата:

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

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

Цитата:

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

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

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

Цитата:

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

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

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

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

[Alexius]

Цитата:

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

Но зато теперь можно будет в качестве аналитики использовать конкретный справочник. Не заводить свой искусственный и заниматься его синхронизацией, а также ограничивать себя в добавлении полей, понимая, что это затронет сразу всю табличку Dimensions.
Т.е. теперь можно будет взять и добавить аналитику Клиент / Проект / Договор / Юрлицо - ссылаяся напрямую на справочник (а-ля субконто в 1С). Также как это сделано в складских аналитиках.

Стоп, а что сейчас (АХ 2009 и ниже) мешает растащить фин аналитики по разным справочникам ? Меняем релейшн и вуаля, да придется немного допилякать, но это на мой взгляд не катастрофично

PS. Я такое не проворачивал
PS2. Справочник Контрагент вообще мечта поэта в РФ

[Pustik]

Цитата:

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

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

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

[TasmanianDevil]

Цитата:

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

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

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

[TasmanianDevil]

Цитата:

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

Стоп, а что сейчас (АХ 2009 и ниже) мешает растащить фин аналитики по разным справочникам ? Меняем релейшн и вуаля, да придется немного допилякать, но это на мой взгляд не катастрофично

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

Лучшей архитектуры фин. аналитики (в плане удобоваримости, потребительской пригодности и запаса прочности к увеличению кол-ва аналитик), чем пара "массив типов ссылок" (зависит от счета) + массив "коды ссылок" еще не придумано. Можно было сделать это в той же таблице, что и сами движения ГК, но ребятки из M$ предпочли вынести это вне таблицы движений по ГК в рамках такой ВАУ-фичи, как unlimited financial dimensions.
Выстрелит это решение еще не раз и по многим местам ...

[Alexius]

Цитата:

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

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

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

[EVGL]

Цитата:

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

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

Ну так и сделано в AX2012.

[TasmanianDevil]

Alexius, рассказывать долго - лучше показать, как оно выглядит в моей интерпретации.
Перечисленных ужасов нет и в помине в этой слегка модифицированной DAX2009
Все по полочками разложено. Отдельно счет, отдельно ссылки на модульные аналитические справочники.
Цена вопроса :

• описатель структуры документов - три таблички
• описатель шаблонов разноски документов - две таблички
• маленький (32 кило) классик-генератор строк разноски для любых документов

Бонусными результатами к положительному решению вопроса о возможности создании счетозависимой аналитики ГК на основании модульных справочников в ходе данной подпольной НИОКР стало:

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

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