Microsoft Dynamics

Disclaimer

В качестве некоторой преамбулы: В этой статье я время от времени буду рассказывать о некоторых чисто финансовых концепциях. Тем не менее, хочу заранее уточнить что я никогда не получал формального образования в области финансов, а самостоятельно учился финансам по переводным книжкам из ООНовсковской серии по финансовому учету и рассказам своих коллег-консультантов с финансовым бэкграундом. Поэтому, вполне вероятно, что часть используемой мною терминологии будет не привычна для людей с классическим российским финансово/бухгалтерским образованием. Тем не менее, я надеюсь , что по сути я не написал ничего принципиально неправильного. Cтатья рассчитана на архитекторов решения, которым важно понимать, как в Dynamics AX сделана работа с ГК, а не вообще как устроен российский и западный учет в абстрактной бухгалтерии.

Читать полностью »

На mibuso.com выложена видеозапись партнерского решения Web Extensions, которое позволяет достаточно просто построить веб-решение для использования данных Microsoft Dynamics.

По настройкам решение напоминает Employee Portal, но предназначено оно для клиентов и поставщиков, т.е. в том числе соответствует требованиям по безопасности.

Читать полностью »

На сайте Hewlett-Packard также опубликован документ с рекомендуемым оборудованием и для Microsoft Dynamics AX для различных инсталляций. Естественно рассматриваются средние (c использованием 3-x уровневой архитектуры) и крупные инсталляции.

Читать полностью »

На mibuso.com выложена демонстрация утилиты для формирования расписания для выполнения различных задач для Microsoft Dynamics AX.

Сама утилита является платной.

Читать полностью »

От пользователей, работающих со старыми версиями Dynamics AX, достаточно часто приходится слышать жалобы на низкую производительность модуля логистики. Что нибудь типа “У нас стоит сервер БД на 4-х двухядерных Xeon (Opteron), 16 гигабайт оперативки  и на небольшой 5 гигабайтной базе, создание строки заказа иногда занимает пару минут”. Если в такой ситуации запустить SQL Enterprise Manager или SQL Server Management Studio, то можно увидеть длинную очередь блокировок процессов, причем все блокированные процессы ожидают освобождения записей в таблице inventSum (Запасы в наличии). Грубо говоря – данная таблица содержит в себе информацию о складском остатке (ну и о количестве зарезервированного, скомплектованного, принятого и т.п. товара) в разрезе кодов номенклатур и кодов складской аналитики. Обновление этой таблицы (опять таки – в старых версиях DAX), организовано следующим образом: При любых модификациях таблицы складских проводок (inventTrans), система находит (или создает) соответствующую запись в таблице запасов в наличии и затем обновляет в ней количество. Естественно – при обновлении записи, до завершения транзакции, обновившей таковую, любой доступ к ней (и по чтению и по записи) из других соединений блокируется. (Случай Dirty Read не рассматриваем). Если у нас не используется учет по партиям или серийным номерам, то с некоторой долей приближения можно сказать, что если мы в транзакции изменили складскую проводку по некоторой номенклатуре и складу, то до конца этой транзакции, пользователи с других рабочих станций  НЕ МОГУТ выполнять какие-то операции по данной номенклатуре на данном складе. Делается это по той простой причине, что до успешного завершения (или отмены) операции, остаток на складе представляет собой некоторую вероятностную величину. Давайте представим себе ситуацию, при которой подобных блокировок не происходит. Допустим - у нас на складе лежит 40 штук некого артикула. Кладовщик в данный момент проводит приходную отборочную накладную с еще 800 штуками. Два сейла резервируют по 20 и 40 штук соответственно. Другой кладовщик оформляет расходную отборочную накладную на 15 штук. Возникает вопрос - сколько у нас вообще на складе свободного товара и можно ли дать третьему сейлу зарезервировать под свой заказ еще 60 штук ? (Кстати – во всем дальнейшем изложении подразумевается , что режим отрицательного склада отключен.)

Читать полностью »

Вышло очередное обновление для Microsoft Dynamics AX 3.0 (заметьте эта версия еще поддерживается:) )

Читать полностью »

Существует следующая достаточно типовая жалоба на производственный модуль DAX: “Мы не можем посчитать себестоимость списания материалов в производство до завершения производственного заказа. У нас на внедрении, цикл производства одного ПЗ занимает 2-3 недели. Получается что материал давно списан из цеховой кладовой, его уже распилили, нарезали и смонтировали, а по бухгалтерии он до сих пор числится на 10ом счету. Даже если мы включим разноску физических складских операций, они не будут включены в закрытие склада, соответственно - истинную себестоимость списания в производство нам не сосчитать до завершения ПЗ. Получается - наш бухгалтерский баланс отстает от реальности на 2-3 недели. Если ПЗ начат и завершен в разных отчетных периодах - это фатально…”.
Читать полностью »

Вчера бывший коллега задал мне именно этот вопрос.Самый банальный подход - просто создать аналогичный журнал, подставив туда количества с обратным знаком - не работает. Во первых - в процедуре редактирования и разноски этого журнала есть куча проверок, которые не дадут этого сделать. Во вторых - этот журнал предназначен для СБОРКИ изделий, но никак не для РАЗБОРКИ таковых. В третьих - если подумать - у нас ведь стоит задача не разобрать чего-то, а просто отсторнировать исходный журнал.
Читать полностью »

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

Читать полностью »

О чем все это?

По моему опыту общения с консультантами и разработчиками, внедряющими DAX, вопросы,связанные с закрытием склада и расчетом себестоимости, стали одними из самых больных на внедрениях. Люди относятся к закрытию склада как к черному ящику, который в зависимости от фазы луны выдает самые разнообразные результаты и отрабатывает за самое разное время. На мой взгляд – это вызвано тем, что информация по процедуре расчета себестоимости разбросана по разным местам документации, кроме того некоторые тонкости этой процедуры вообще нигде не описаны и их приходится изучать методом проб и ошибок или изучая исходные тексты процедуры закрытия склада.

Читать полностью »

При внедрении DAX часто возникает примерно следующая задача: Клиент говорит что-нибудь типа “Мне нужно добавить в заказы (складские журналы, закупки, производственные заказы и т.п.) новое поле - направление продаж (код продавца, номер автомобиля для отгрузки, идентификатор кредитной линии клиента и тп). Кроме того - мне нужно уметь строить отчеты (обычные или OLAP) по складским списаниям (приходам) в разрезе этого нового поля”.

Читать полностью »