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

[Stitch_MS]

Коллеги,

Я работаю в MDCC, в команде, ответственной за Cost Management в Dynamics AX. Сейчас мы тут обсуждаем, на что должна быть похожа система управления затратами в AX 2015 (или как её в конце концов назовут).



В связи с этим прошу высказаться на тему "себестоимость, управление затратами и калькуляция в стандартном функционале Dynamics AX", как-то :

• что хорошо
• что не очень
• за что поотрывать руки разработчикам
• чего не хватает
• что не доделано
• что не продумано
• что трудно локализовать
• Business Intelligence - надо ли такое для системы управления затратами, и если надо, то чего ждут пользователи
• прочее

Вообще говоря, приветствуются любые конструктивные мысли на эту тему.

Мысль, что "в Майкрософте должны понимать, что Аксапта - это среда разработки, и она всё-равно будет допиливаться под конкретного клиента", уже усвоена.

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

Заранее благодарю за сотрудничество.

С уважением,
Александр

[EVGL]

В российской и турецкой бухгалтерии принято относить на себестоимость производства не только прямые затраты на сырье и нормо-часы, как предписывает МСФО, но и зарплаты рабочих, амортизацию машин, электроэнергию и прочие расходы на производство. Пока это возможно в AX только в полуручном режиме с помощью allocation + cost adjustment.

В ядро надо интегрировать возможность включения транспортных и прочих расходов в себестоимость сырья. Эта возможность реализована в российской локализации выше AX2009 RU4, причем довольно неплохо: "распределение счетов на другие счета". Это требование есть во всех стандартах бухгалтерского учета, от Лондона до Владивостока. Наш консультант по австрийским финансам был в восторге, когда открыл эту фичу.

Тема не совсем та, но разноска picking list в AX не совсем соответствует стандартам западного учета. Проводка Д Баланс - К Баланс или Д Затраты - К Баланс обе не очень хороши и вызвают вопросы у аудиторов. Думаю, ваши аналитики уже давно в курсе, но ничего не делают.

В стандарте нет возможности отнести потребление материалов сразу на несколько производственных заказов по некоей базе распределения. Пример: засыпыем в машину мешок полиэтилена, но не знаем в точности, сколько килограммов пошло за заказ номер 3 из группы 5 однотипных заказов.

Самый фатальный недостаток: за пределами модуля Process нельзя из одного производственного заказа сделать несколько продуктов (by-product). Не распределяются затраты, нет возможности учесть это в сводном планировании. Эта модификация настолько сложна, что почти нет партнеров, которые могли бы подступиться к проблеме и решить ее во всей полноте. Некий муляж опять-таки есть в российской локализации, но только муляж.

[Raven Melancholic]

Цитата:

все ваши пожелания будут переведены на английский

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

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

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

[Logger]

Цитата:

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

...

• что не доделано
• что не продумано

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

Ачуметь !
Вот это здорово !

Прошу вас обратить внимание на тему:
пересчет себестоимости в журналах переноса?

Расчет себестоимости работает с ошибками при определенных условиях. Так что если быть совсем честными, то никакого расчета себестоимости в разрезе финансовых аналитик хранения в Аксапте нет. Себестоимость может перемешиваться для разных значений аналитик, независимо от настроек, при переносах и заполнении лота возврата и при маркировке.

[Logger]

Я бы еще подумал над развитием средств выверки главной книги и складского модуля.
Основное место претыкания для финансовых аналитиков - возможность скорректировать текущей датой проводки предыдущего периода.

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

Хорошо бы иметь какое-нить средство, интуитивно понятное большинству пользователей. Конкретных предложений пока предоставить не готов.

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

берите все лучшее из модуля CO SAP

[xan]

Цитата:

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

берите все лучшее из модуля CO SAP

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

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

важны не объекты а идеология контроллинга

[fed]

Цитата:

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

берите все лучшее из модуля CO SAP

If you want SAP, you know where to find it.

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

САП просто лучше всего воплощает достижения экономической науки.... пора Майкрософту перейти от блужданий в плане технологий к выстраиванию своей идеологии управления

[fed]

Цитата:

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

САП просто лучше всего воплощает достижения экономической науки.... пора Майкрософту перейти от блужданий в плане технологий к выстраиванию своей идеологии управления

А что же ты тогда на Аксаптовском форуме делаешь солнышко ?

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

за державу обидно )))

[fed]

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

Второй подход - в чем-то более системный, но полностью ломающий совместимость. Можно завести таблицу иерархии затрат, таблицу проводок по затратам и новый тип счета в журлале ГК -Затраты. Только схема эта чревата боком, потому что:
1. Необходимо будет динамически формировать иерархию затрат. То есть - грубо говоря, если у вас есть веточка "затраты на транспортировку", то как-то надо будет дать возможность относить затраты и на транспортировку вообще, и на конкретную закупку. Я пока не очень понимаю как это можно сделать системным способом.
2. Вам явно придется закладывать в систему некоторую предопределенную модель иерархии затрат (хотя бы для того чтобы затраты по каждому модулю прикрепить к определенному месту). Наличие предопределенной иерархии явно сделает систему менее гибкой и приведет к тому что она будет хуже ложиться на потребности клиентов. Учитывая традиционно похабную документацию, в которой пишут про галочки, а не про экономическую модель, уверен что партнеры не смогут разобраться с этой моделью и будут жостко и противоестественно насиловать ее на каждом внедрении. Ну то есть - хотите использовать предопределенные отраслевые модели - на здоровье. Только хорошо бы эти модели были бы хоть как-то документированы...
3. Ну и естественно - первое время вся переписанная функциональность будет жутко глючить (просто по другому быть не может). А учитывая качество поддержки и традиционную нелегкость регистрации в ней багов - процесс исправления ошибок (я говорю не об ошибках дизайна, а о тупых кодерских багах), может очень затянуться.

Собственно - я верю что вариант номер 2 возможен, но не советовал бы вам его рассматривать в отрыве от состояния канала продаж/поддержки/работы с партнерами/документирования. Надеюсь вы помните, дорога в какое место выстлана благими намерениями...

[Serg]

Сделайте как в NAV – разделите проводки по количеству и стоимости в разные таблицы, таким образом, что бы к движению по количеству можно было добавлять связаны с ним расходы, с любой аналитикой.

[mazzy]

Цитата:

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

В связи с этим прошу высказаться на тему "себестоимость, управление затратами и калькуляция в стандартном функционале Dynamics AX", как-то :

• что хорошо
• что не очень
• за что поотрывать руки разработчикам
• чего не хватает
• что не доделано
• что не продумано
• что трудно локализовать
• Business Intelligence - надо ли такое для системы управления затратами, и если надо, то чего ждут пользователи
• прочее

Вообще говоря, приветствуются любые конструктивные мысли на эту тему.

круто.
добавлю к предыдущим ораторам.

Очень хочется накладные расходы на хранение.
Т.е. сумма появляется за факт хранения остатков.

сейчас можно сэмулировать только выполнив коррекцию себестоимости у открытых приходов. что не очень правильно. поскольку бывают неотфактурованные и/или несопоставленные расходы.

[mazzy]

Цитата:

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

Сделайте как в NAV – разделите проводки по количеству и стоимости в разные таблицы, таким образом, что бы к движению по количеству можно было добавлять связаны с ним расходы, с любой аналитикой.

можно.
да. но такая система обладает и своими недостатками.
прежде всего она становится очень сложной для контроля.

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

[ppson]

1) сделать модуль Process in Work
2) сделать модуль сбора затрат отдельным от ГК, интегрировать учет/распределение затрат с закупками/заказами/складским модулем/производством/product builder/журналами ГК, что бы можно было планировать и собирать затраты в НЗП/номенклатуры в разрезе статей затрат на любом этапе производственной деятельности - при закупках, производстве, на складе, при продаже. Транзакции по затратам должны собираться не из ГК, а из данного модуля.
3) сделать модели в складском модуле/учете затрат, что бы закрывать склад/распределять затраты можно было бы по разным стандартам.

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

реализовать функционал внутренних заказов, на которые бы аккумулировались затраты.

[fed]

Цитата:

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

реализовать функционал внутренних заказов, на которые бы аккумулировались затраты.

По моему, это модуль проекты делает. Там два типа проекта для этого есть - Внутренний и Инвестиционный...

[mazzy]

Цитата:

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

2) сделать модуль сбора затрат отдельным от ГК, интегрировать учет/распределение затрат с закупками/заказами/складским модулем/производством/product builder/журналами ГК, что бы можно было планировать и собирать затраты в НЗП/номенклатуры в разрезе статей затрат на любом этапе производственной деятельности - при закупках, производстве, на складе, при продаже. Транзакции по затратам должны собираться не из ГК, а из данного модуля.

уже есть. модуль проекты
http://axapta.mazzy.ru/lib/projectmodule/

Цитата:

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

3) сделать модели в складском модуле/учете затрат, что бы закрывать склад/распределять затраты можно было бы по разным стандартам.

закрытие уже вроде есть по разным моделям.
распределять затраты... если из модуля проекты - то уже можно.