popov19, Navision - классическая OLTP система, Заложенный стандартный функционал, скорость работы и перевариваемые объемы позволяют успешно конкурировать с известной желтой системой, не смотря на немалый ценник.
Попытки прилепить серьезный анализ/отчетность данных к Nav - старинная российская забава из разряда "впихнуть невпихуемое и плакать что плохо работает".

Как только вы залезете достаточно глубоко с достаточно тяжелыми SQL запросами извне или изнутри в процессы, ваши пользователи заплачут от того, что система начнет виснуть.

Классическое решение - создание отдельной аналитической базы, сливание в неё из Nav подготовленных в нужных разрезах данных и
получение необходимых отчетов любыми предназначенными для этого средствами.
Дополнительный бонус от данного решения - для повышения производительности базу Nav периодически можно компрессить/обрезать.

rmv_RUdmitespopov19, Navision - классическая OLTP система, Заложенный стандартный функционал, скорость работы и перевариваемые объемы позволяют успешно конкурировать с известной желтой системой, не смотря на немалый ценник.
Попытки прилепить серьезный анализ/отчетность данных к Nav - старинная российская забава из разряда "впихнуть невпихуемое и плакать что плохо работает".

Как только вы залезете достаточно глубоко с достаточно тяжелыми SQL запросами извне или изнутри в процессы, ваши пользователи заплачут от того, что система начнет виснуть.

Классическое решение - создание отдельной аналитической базы, сливание в неё из Nav подготовленных в нужных разрезах данных и
получение необходимых отчетов любыми предназначенными для этого средствами.
Дополнительный бонус от данного решения - для повышения производительности базу Nav периодически можно компрессить/обрезать.
Категорически не согласен. Прикручивали серьезную аналитическую отчетноcть в том числе и через SQL запросы на достаточно больших объемах данных (базы за 100 Гигов). Отдельная аналитическая база также имеется, но больше как консолидационная для разных баз Нава и других учетных систем (в и.ч. с желтым ценником). Для построения отчетности по одной базе - овчинка выделки не стоит. С необходимостью компрессить и обрезать базу для повышения производительности (учета видимо?), в силу архитектуры построения тоже не сталкивались.

Текущая база 400 Gb. Один единственный отчет с SQL запросом. Запускают в Пн группа закупщиков каждый по своим договорам. Запрос тяжелый - выполняется 15-20 сек.
Результат - До обеда Пн можно идти курить. В остальное время - небольшие проблемы только с пакетным одновременным учетом

ДжекНепотрошительdmitespopov19, Navision - классическая OLTP система, Заложенный стандартный функционал, скорость работы и перевариваемые объемы позволяют успешно конкурировать с известной желтой системой, не смотря на немалый ценник.
Попытки прилепить серьезный анализ/отчетность данных к Nav - старинная российская забава из разряда "впихнуть невпихуемое и плакать что плохо работает".

Ой, только не надо про скорость работы. Учитывая архитектуру базы данных NAV (отсутствие автоинкрементов -> все идентификаторы считаются как "select max([Entry No_]) + 1 from <table name>", соответственно, с блокировками таблиц), скорость ее работы в сравнении с другими системами удручает.

dmitesПС. А как Navision данные хранит?
Может есть возможность просто взать данные с SQL сервера и не парить мозги с выгрузками?

Хранит или в нативной базе, или на MS SQL. Во втором случае именно так и нужно делать, т.к. встроенные средства отчетности в ней рудиментарны в сравнении с теми же Reporting Services. Благо, это не 1С, здесь физическая структура базы данных идентична логической.

"Надо Федя. Надо" (с)
Личный опыт минимум в 3-х компаниях. Торговые сети от 50 магазинов и от 50 одновременных пользователей.
То что переваривает стандартный Nav, 1C со стандартной конфой и не снилось.

rmv_RUДжекНепотрошительпропущено...

ИМХО, здесь причина в наследственности, а не в отсутствии решений. NAV вырос из нативной БД, в которой такая возможность просто отсутствовала (поправьте меня, если ошибаюсь).
Сделать "внетранзакционный" генератор последовательностей номеров - не есть технологическая проблема. Во многих СУБД есть генераторы или sequence, в принципе, и identity для этого можно приспособить.
MS, как мне кажется, до этого просто еще не добрался, учитывая весь объем работ, который нужно провести с NAV для ее "осовременивания", т.е. полной миграции на ролеориентированный клиент, трехзвенку и дотнет в качестве платформы разработки.

Думаю здесь проблема в другом.
Учет подразумевает, что определенные данные зафиксированы на момент учета (кредитный лимит клиента - просроченные платежи к примеру или остаток по товару) и изменению не подлежат. Паралельный учет подразумевает огранизацию программного кода таким образом, чтобы однозначно исключить фантомы при проверки валидности учета (учет покупки, одновременно учет продажи, продажу закоммитили, покупка свалилась с ошибкой - в итоге сидим в минусах) . Стандартный код решил за всех и кардинально, блокируя последних записи книгах операций. Подход имеет место быть, однако есть при необходимости можно организовать и паралельный учет на критичных участках, блокируя либо определенные диапазоны, либо справочники вместо учетных таблиц.

Двигался по этому пути. Удалось распараллерить полностью вплоть до фантомов из спортивного интереса.))
А в целом вы абсолютно правы. Проблемка решается именно так