Microsoft Dynamics NAV, как и многие другие схожие программные продукты, имеет модульную структуру.

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

Определение необходимого набора модулей или еще говорят конфигурации лицензии определяет стоимость продукта (стоимость лицензии).

От пользователей, работающих со старыми версиями 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 штук ? (Кстати – во всем дальнейшем изложении подразумевается , что режим отрицательного склада отключен.)