"Управление затратами" в следующей версии Dynamics AX - ваши пожелания

[Logger]

Цитата:

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

Мирослав, может проще было написать : "Возьмите книгу "Контроллинг затрат на продукт с помощью решений SAP" и сделайте, как там написано.
Вполне конкретное требование.

Неужели САП не имеет недостатков в этой части ?

[fed]

Цитата:

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

Неужели САП не имеет недостатков в этой части ?

Более правильный вопрос - "А зачем нам второй САП?".

[Logger]

Цитата:

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

Более правильный вопрос - "А зачем нам второй САП?".

Еще более правильный вопрос - мы хотим сделать конкурентный продукт или нет ?

Или будем и дальше смотреть, пока под победные реляции об улучшении (торможении ) ядра прикладная часть стагнирует, а рынок аксапты плавно съеживается между 1С и сапом.

Кстати мой вопрос выше был с намеком - зачем повторять САП, может сразу нацелиться на что-то лучшее ?

[fed]

Цитата:

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

Еще более правильный вопрос - мы хотим сделать конкурентный продукт или нет ?

Или будем и дальше смотреть, пока под победные реляции об улучшении (торможении ) ядра прикладная часть стагнирует, а рынок аксапты плавно съеживается между 1С и сапом.

Кстати мой вопрос выше был с намеком - зачем повторять САП, может сразу нацелиться на что-то лучшее ?

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

Лучше бы они фундаментальные вещи и фундаментальные ПРИКЛАДНЫЕ фреймворки расширяли. А тех кто рвется интерфейс вылизывать или на .net все переносить - лучше бы в группу bing подарили. (Там такая засада, что плюс-минус 100-200 придурков ничем не ухудшат ситуацию).

Кроме того - попытки слизать функциональность с конкурентов не разбираясь с ней и не понимая Аксапту, уже привела нас к новой архитектуре ГК, слизанной, как я понимаю, с OEBS.

[xan]

Цитата:

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

Более правильный вопрос - "А зачем нам второй САП?".

Денис, ты как всегда точен.

По моему мнению? вопрос не в копировании какой-либо ERP системы, а в инкорпорировании какой-либо методологии. Учет затрат в Axapta строится на бухгалтерских счетах, учет в SAP строится на объектах (МВЗ, работах (проекта) и т.д.).
Да, умельцы - "дотачиватели" делают красивые решения по учету на тех же МВЗ с помощью аналитик к бухгалтерским счетам, но это имитация по своей сути (что ни в коей мере не умоляет профессионализма тех, кто это делает).
Субконто и прочие радости "из мира учета затрат на счетах" улучшат функциональность системы, но "дотачивателям" всё-равно придется извращаться, чтобы сымитировать учет по МВЗ.

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

Так что же нужно: другая методология или расширение функциональных возможностей существующей?!

[mazzy]

Цитата:

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

Учет затрат в Axapta строится на бухгалтерских счетах, учет в SAP строится на объектах (МВЗ, работах (проекта) и т.д.).

Нет.
В Аксапте модуль Проекты.

[xan]

Цитата:

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

Нет.
В Аксапте модуль Проекты.

Я очень давно работал с Аксаптой и то, что знал, тоже забыл, а модуль проекты зналь очень плохо

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

[Мирослав Лянцевич]

и в модуле и на счетах ГК....

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

[Мирослав Лянцевич]

в этом случае саповская идеология контроллинга с заведением БЕ-независимой controlling area попадает в яблочко...

[Мирослав Лянцевич]

вот именно... в аксе всю аналитику нужно собирать по сусекам, в сапе она представляет из себя самостоятельные объекты, на базе которых можно строить p&l-и...

Цитата:

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

Денис, ты как всегда точен.

По моему мнению? вопрос не в копировании какой-либо ERP системы, а в инкорпорировании какой-либо методологии. Учет затрат в Axapta строится на бухгалтерских счетах, учет в SAP строится на объектах (МВЗ, работах (проекта) и т.д.).
Да, умельцы - "дотачиватели" делают красивые решения по учету на тех же МВЗ с помощью аналитик к бухгалтерским счетам, но это имитация по своей сути (что ни в коей мере не умоляет профессионализма тех, кто это делает).
Субконто и прочие радости "из мира учета затрат на счетах" улучшат функциональность системы, но "дотачивателям" всё-равно придется извращаться, чтобы сымитировать учет по МВЗ.

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

Так что же нужно: другая методология или расширение функциональных возможностей существующей?!

[mazzy]

Цитата:

Сообщение от Мирослав Лянцевич

вот именно... в аксе всю аналитику нужно собирать по сусекам, в сапе она представляет из себя самостоятельные объекты, на базе которых можно строить p&l-и...

как раз наоборот

[fed]

Цитата:

Сообщение от Мирослав Лянцевич

вот именно... в аксе всю аналитику нужно собирать по сусекам, в сапе она представляет из себя самостоятельные объекты, на базе которых можно строить p&l-и...

Жесткая завязка аналитики на фиксированные объекты учета приведет к снижению гибкости и адаптируемости системы. Не уверен что в среднем-среднем и верхнем-среднем сегментах рынка это будет правильным решением. Кроме того, учитывая что микрософт отраслевых решений толком не делает, а одним общим решением всю отраслевую специфику не покроешь, не факт что переход к использованию объектов учета будет оправдан. Возможно - да, а возможно - и нет. Так что всякое проектное решение имеет свои ограничения и минусы, разговоры про "Сделать как в SAP" не учитывают что SAP изначально ориентирован на другой сегмент рынка...

[Мирослав Лянцевич]

позиционирование объясняется происхождением...

САП воплощение немецкой школы учета, для которой учет - точная наука... Акса - американская система, в которой учет это проявление психологии... Отсюда отсутствие конкретных объектов и шаблонов...

[Мирослав Лянцевич]

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

[George Nordic]

Цитата:

Сообщение от Мирослав Лянцевич

позиционирование объясняется происхождением...
САП воплощение немецкой школы учета, для которой учет - точная наука... Акса - американская система, в которой учет это проявление психологии... Отсюда отсутствие конкретных объектов и шаблонов...

Надеюсь, Вы шутите? Как раз в Штатах DAX - не распространена, там есть Microsoft Dynamics SL (Solomon) и Microsoft Dynamics GP (Great Plains). Могу показать диск Damgaard Axapta 2.0, возможно, вспомните, что AX изначально являлся Европейской системой, и большинство инсталляций - именно в Европе.

С Уважением,
Георгий