Microsoft приглашает партнеров принять участие в тренингах по Microsoft Dynamics AX 2009.
Производительность NAV 2009 выше, чем у AX 2009
К такому заключению привели результаты теста, проведенного командой Thrifty Software Building.
Разработанный ими инструментарий Locking Free NAV 2009, являющийся методологией модификации и разработки, позволяет существенно повысить производительность и исключить блокировки.
Тест проводился для:
- 47 000 документов покупки и продажи - 235 000 строк документов в час;
- 10 000 клиентов;
- 10 000 товаров;
- 10, 20, 30 и 40 активных пользователей.
При тестировании не было выявлено ни одного Deadlocks и Lock Timeouts.
Тестирование проводилось без Application Server, использование которого могло бы потенциально привести к увеличению количества строк до уровня более 300 000 строк в час.
Производительность Locking Management превышает стандартную конфигурацию более чем в 20 раз, а также AX 2009 при одинаковых условиях тестирования.
Друзья, как вы знаете недавно обновился российский сайт по Microsoft Dynamics! Теперь он имеет общий со всем Microsoft интерфейс.
Я решил проверить описание продуктов AX и NAV.
Итак, для AX:
потребность в автоматизации – от 20 до 500 одновременно работающих пользователей (на практике существуют инсталляции с числом пользователей более 1000, а также тестовые инсталляции для 3000 одновременно работающих с системой и более 32 тыс. обычных пользователей);
Читать полностью »
Disclaimer
В качестве некоторой преамбулы: В этой статье я время от времени буду рассказывать о некоторых чисто финансовых концепциях. Тем не менее, хочу заранее уточнить что я никогда не получал формального образования в области финансов, а самостоятельно учился финансам по переводным книжкам из ООНовсковской серии по финансовому учету и рассказам своих коллег-консультантов с финансовым бэкграундом. Поэтому, вполне вероятно, что часть используемой мною терминологии будет не привычна для людей с классическим российским финансово/бухгалтерским образованием. Тем не менее, я надеюсь , что по сути я не написал ничего принципиально неправильного. Cтатья рассчитана на архитекторов решения, которым важно понимать, как в Dynamics AX сделана работа с ГК, а не вообще как устроен российский и западный учет в абстрактной бухгалтерии.
Веб-решение для Microsoft Dynamics
На 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 недели. Если ПЗ начат и завершен в разных отчетных периодах - это фатально…”.
Читать полностью »
Вчера бывший коллега задал мне именно этот вопрос.Самый банальный подход - просто создать аналогичный журнал, подставив туда количества с обратным знаком - не работает. Во первых - в процедуре редактирования и разноски этого журнала есть куча проверок, которые не дадут этого сделать. Во вторых - этот журнал предназначен для СБОРКИ изделий, но никак не для РАЗБОРКИ таковых. В третьих - если подумать - у нас ведь стоит задача не разобрать чего-то, а просто отсторнировать исходный журнал.
Читать полностью »




