Сравнение масштабируемости Navision и Axapta

[alxm]

Здравствуйте. Хочется развить тему, вскользь упомянутую в соседнем топике, про сравнению Navision и Axapta с 1С.
Конкретно, о пределах масштабируемости Navision.
Конечно, эта тема поднималась уже не раз, но к сожалению, чаще всего обсуждается макс.количество одновременных
пользователей и размер базы в гигабайтах. Если с количеством пользователей более-менее ясно, то размер базы навижн
мне мало о чем говорит. Можно ли вместо этого обсудить количество документов, строк документов? Скажем 50 млн записей в sales line в год
это много? (это сейчас) а 150-200 млн? (это планируется)
Другой вопрос - скорость ввода и учета документов. За сколько времени можно создать и учесть 100 документов по 1000-3000 строк в каждом?
(ежедневная загрузка данных с POS).

ну и раз уж тут раздел "сравнение систем", то было бы вполне уместно устроить сравнение. Типа "а вот у нас, в Астор Торговая сеть 6.0 все зашибись, 200-300 млн
строк вообще не вопрос"

[mazzy]

Цитата:

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

Типа "а вот у нас, в Астор Торговая сеть 6.0 все зашибись, 200-300 млн строк вообще не вопрос"

Хм... А почему в заголовке только Navision и Axapta?

Согласитесь, что получится очень нехорошо, если мы начнем говорить о проблемах и решениях для Navision и Axapta, а про Астор Торговая сеть будет известно только то, что там "все зашибись"

Начали про Астор, так расскажите.

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

Расскажите, как Астор Торговая сеть использует движок 1С, а где работает напрямую (неужели в заказах и при работе с POS-терминалами? ни за что не поверю )

Расскажите, может ли Автор Торговая сеть импортировать несколько заказов одновременно из разных POS-ов или не может (как решили проблему блокировок).

Расскажите, какие проводки и какие движения в каких регистрах делаются в заказах Астор Торговая сеть.

Дело в том, что Заказы и Закупки в Навижине и Аксапте имеют очень четкий и известный всем функционал, а вот каким образом Астор добился чтобы было "все зашибись" мало кто знает. Поэтому расскажите об Асторе.

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

Итак, очень ждем рассказа.

[alxm]

Цитата:

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

Хм... А почему в заголовке только Navision и Axapta?

Согласитесь, что получится очень нехорошо, если мы начнем говорить о проблемах и решениях для Navision и Axapta, а про Астор Торговая сеть будет известно только то, что там "все зашибись"

Начали про Астор, так расскажите.

Итак, очень ждем рассказа.

Хм.
К сожалению, рассказа от меня не будет. Понятия не имею про Астор. Привел его толко потому, что он в моем списке претендентов, и потому
что его начали обсуждать в соседней теме. Ну и мне показалось, что я попал в нужное время в нужное место. Голова уже опухла от сравнения
и общения с сейлзами, у которых "все зашибись" всегда, а на конкретные вопросы по производительности конкретных ответов нет.
Очень буду рад, если кто-нибудь расскажет про Астор, кто уже сравнивал. Мне это только предстоит в ближайшее время
Ну и не хотелось бы уйти от обсуждения производительности.

p.s. Да, на всякий случай, я смотрю не стандартный Navision, а решения для розницы. конкретно LS Retail сейчас.
p.p.s. Кстати, серийные номера и резервирование не актуально, продукты в розницу продаем. Это же благотворно скажется на производительности?

[mazzy]

Цитата:

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

К сожалению, рассказа от меня не будет. Понятия не имею про Астор.

жаль.

Цитата:

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

Очень буду рад, если кто-нибудь расскажет про Астор, кто уже сравнивал.

Понятно. Задайте им вопросы, которые я озвучил

Цитата:

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

p.p.s. Кстати, серийные номера и резервирование не актуально, продукты в розницу продаем. Это же благотворно скажется на производительности?

Конечно. Если импорт будет происходить монопольно, то не будет проблемы блокировок.
Может быть для вас не актуальна и проверка отрицательных остатков?
В общем, чем меньше выполняется действий при учете заказа, тем больше будет "зашибись".

Теперь о стандартном функционале и правильная организация работы.
Заказы, Закупки и Журналы - суть черновики в Навижине и в Аксапте.
Пока документ находится в состоянии черновик, с ним можно делать все что угодно.
Учет/Разноска/Проведение черновика переносит всю информацию в другие таблицы (в фактические документы).
После Учета/Разноски/Проведения черновик может и должен быть удален (к сожалению, в россии люди привыкли к 1С и не удаляют)

Если черновики удаляются, то появляется очень логичный смысл этих документов.
Черновик - это то, что предстоит сделать.
Фактический документ (накладная/счет-фактура) - это то, что уже сделано и ни в коем случае не меняется.


В свете этого ваш вопрос о большом количестве строк в заказах не имеет особого смысла для Аксапты и Навижина. Строк в заказах не должно быть так много. Фактических документов может быть очень много.
Указанная вами цифра "50 млн записей в sales line в год" - это достаточно тяжелая нагрузка. Говорить, что будет "все зашибись" - это конечно же авантюризм. Но особых подозрений или криков "ни в коем случае" лично у меня не возникает: Нормально будет работать стандартный функционал (с проверкой отрицательных, с резервированием, с партиями, с возвратами, с бухгалтерскими/складскими и налоговыми проводками, с одновременным учетом нескольких заказов и немонопольным проведением, на стандартном движке без привлечения прямого доступа к СУБД).

Да, надо будет настраивать производительность.
Да, надо будет шаманить с индексами.
Но это и есть работа внедренцев.

[alxm]

Цитата:

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

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

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

Цитата:

Указанная вами цифра "50 млн записей в sales line в год" - это достаточно тяжелая нагрузка. Говорить, что будет "все зашибись" - это конечно же авантюризм. Но особых подозрений или криков "ни в коем случае" лично у меня не возникает:

а 150-200 млн? Мне примерно такой рост обещают на ближайший год-два. Очень не хочется каждые два года пере-автоматизироваться.
есть ли в этом смысле принципиальные отличия между navision и axapta?

[mazzy]

Цитата:

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

а 150-200 млн?

Пригласил поучаствовать в этой ветке человека, у которого был примерно такой объем.
Если он посчитает нужным, ответит.

Пока мой ответ - как настроите.
Обещать что "все будет зашибись" я бы с ходу не стал. Поскольку это достаточно серъезная нагрузка.
Зависит от количества пользователей, от железа, от того функционала который будет задействован.

Цитата:

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

есть ли в этом смысле принципиальные отличия между navision и axapta?

есть.
в текущих версиях в Навижине используется оптимистическая блокировка, в Аксапте транзакционная пессимистическая.

Это значит, что Навижин узнает о том, что не может записать, в самом конце транзакции и делает откат с ошибкой.
Аксапта же будет ждать СУБД, пока СУБД сможет начать транзакцию.

В следующих версиях будут серьезные изменения в Навижине по работе с СУБД.

[Dzemon]

Ну у вас же розница!
Тут несколько другой подход.
1. Скорость ввода и объем приходных накладных?
2. Кол-во касс?
3. Кассы онлайн или оффлайн?
4. Кол-во чеков в день и среднее кол-во товаров в чеке?
5. Сеть магазинов?
6. Взаимодействие с центральным офисом?
7. Центральный или распределенных склады?
8. Логистика?

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

[alxm]

Цитата:

Ну у вас же розница!

Ох. Ну да, все так. Есть только один момент. Ладно, сначала по пунктам
1) накладных на магазин в день штук 90, строк в каждой от 1 до 100. ну скажем в среднем 20-30.
2) 10-20 на магазин
3) кассы офф-лайн
4) вот сейчас не знаю, и ниже расскажу почему. статистику можно поднять
5) сеть
6) да
7) складов нет
8) нет
Сейчас у нас все организовано очень просто.
Каждый магазин работает в своей базе, данные один раз в день передаются в центральный офис. Именно поэтому я не знаю наизусть статистику
по чекам, в офис с касс передаются z-отчеты. (но данные по чекам есть в программе по дисконтным картам)
Распределительного центра тоже нет, товар возят сразу в магазины поставщики. А вот заказы для магазинов
делаются в основном в центральном офисе. Вот так и получается та картина, что я описал раньше. Большое количество документов попадает в систему автоматически,
один раз в день.
На первом этапе схема работы сохраняется, но требуется увеличить "мощность", т.к. число магазинов увеличится, да и сейчас скорость оставляет желать.
А вот на втором этапе схема работы может поменяться и магазины начнут работать сразу в центральной базе (кроме касс конечно) А может и не начнут, вот например
у LS Retail есть репликатор.
P.S. Это все о производительности. Конечно, это не единственная цель, это только одна из целей. Но если о функционале можно многое понять заранее, посмотреть демо
и т.п. то о том, что и где будет тормозить сейлзы рассказывать не любят, да и не знают наверное.

[Dzemon]

Ну, про тормоза попробую рассказать ;-)
1. Взаимодействие с кассами. Если кассы оригинальные, то в них надо закачать справочники и из них выгрузить чеки. Если фискальные регистраторы на навижиновском/аксаптовском ф-ле, то проще, но зависят от работы магазинного сервера.
2. Учет Открытого Отчета (фактически чеков) занимает порядочно времени......
3. Обмен с ЦО. Ну тут менеджеры требуют ВСЮ информацию из магазинов, а это немало! Если каналы связи хреновые, то могу Вам посочувствовать. Тут либо оптимизировать передаваемую информацию, либо широкие каналы. Это основная проблема. Если канал достаточный, то репликатор отлично справляется, но в ЦО база очень быстро разрастается!!!!
4. Ну и еще документооборот типа переброски товара из одного магазина в другой, единая база дисконтных карт, маркетинговые акции (не верьте менеджерам, говорящим что не бывает двойных скидок!!! ;-))

Схема работы вашей фирмы мне знакома ;-) Попробую предвидеть следующий шаг: Вы открываете магазин в новом монстровом торговом центре (МЕГА какая-нибудь, к примеру) в черте города, а там есть ограничение на время разгрузки товара - только ночью и строго по графику. В результате делают буферные склады... Ну и появляется сложная логистика ;-)

[sergeypp]

НУ у нас объемы немного меньше.. Я примерно прикинул SALESLINE за месяц увеличилась на 117444 строк, SALESTABLE на 27026
Т.е. получается что за год у нас создается около 300000 заказов и около 1500000 строк.. Но ведь нельзя оценить производительность системы только по кол-ву заказов. Существуют как минимум еще и внутренние перемещения, а их кол-во зависит от внутренней логистики организации. Уж поверьте они тоже хорошо "напрягут" систему. Если у вас такие объемы, готовьте деньги на хорошую железку. Это про аксапту. Что касается Navision, то в той организации, где я работал, объемы были и вовсе меньше. Но в данном случае предпочтительней использовать все таки Аксапту. Нав может и не справиться. Кстати в Наве при учете заказа, сам заказ исчезает(вернее на его основе формируются другие документы в других таблицах), а в Аксапте заказы остаются, хранить их или нет дело сугубо личное.

[mazzy]

Цитата:

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

Кстати в Наве при учете заказа, сам заказ исчезает(вернее на его основе формируются другие документы в других таблицах), а в Аксапте заказы остаются.

Вернее так: В Наве нет выбора - заказы после обработки удаляются и переходят в фактические документы.
В Аксапте можно удалять, а можно оставить. (Лучше бы этой галки не было )

[Dzemon]

Цитата:

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

НУ у нас объемы немного меньше.. Я примерно прикинул SALESLINE за месяц увеличилась на 117444 строк, SALESTABLE на 27026
Т.е. получается что за год у нас создается около 300000 заказов и около 1500000 строк..

Это немного даже для Навижина. Есть другая засада - аналитика! Чем больше Глобальных Измерений, тем быстрее растет база и медленнее идет учет.

[RedFox]

Цитата:

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

Это немного даже для Навижина. Есть другая засада - аналитика! Чем больше Глобальных Измерений, тем быстрее растет база и медленнее идет учет.

Не забывайте, что чем больше измерений, тем дольше учет, .. блокировка, .. и все с этим связанное.

Кстати, LS-retail с версии 4.20 без проблем все это переварит (они переделали малеха структуру СВОИХ журналов по сравнению с версией 3.60 и совсем отказались от стандарных решений на базовых таблицах типа 36,37, ... с жуткими надстройками). Правда если правильно организовать процесс учета. И чеки ненадо будет.
Репликатор тоже работает как по часам, так и по правилам. И скорость неплохая + "механизм бысрого открытия".

Но если кол-во магазинов будет более 40-50 с 10-20 кассами на борту, то могут быть проблемы с производительностью и ростом жунал из-за разбиения по магазинам...
Можно использовать связку Navision (магазины) и Axapta в ЦО (кстати, DD у LS может коммуницировать со многими системами).

P.S. Кстати, нужно будет доделать работу с драйверами фискального регистратора.

[alxm]

ОК. Спасибо за ответы и комментарии. Я попробую резюмировать, что я понял для себя
- Navision _в_принципе_ потянет, но _на_всякий_случай_ лучше ориентироваться на аксапту,
она потянет точно. В любом случае секса с настройкой SQL не избежать...

[sanya_123]

недавно занимался сайзингом (нагрузочным тестирование) Navision.
тестировали при разных размерах БД (до 40 ГБ) и разной интенсивности учета.

Так вот, увеличение размера БД напрягает намного меньше, чем увеличение числа одновременно учитывающих пользователей.
например, на нашем оборудовании, при увеличения размера бд с 10 до 20 ГБ и скорость построения отчетов, и скорость учета падала на 10%, а при увеличении числа одновременно учитывающих пользователей в полтора раза скорость учета может снизиться в разы.

Другими словами, самое слабое место Navision с точки зрения производительности- учет. Все ломятся в одно и то же место (GL Entry и т д), происходят блокировки, которые пытается разрулить сам MS SQL => тормоза.

Будем решать, скорее всего, через перенос учета на отдельно выделенный NAS (это доработка системы)
В axapta, насколько я понимаю, таких проблем нет - там роль "диспетчера" выполняет сервер приложений.

[Dzemon]

А какая версия была? Сколько пользователей?
Есть еще проблема - плохо сконфигурированный SQL сервер как в настройках так и в железе. У него возникает проблема распределения собственных ресурсов, что в навижине отражается как блокировка сессии пользоваля этой же сессией.

[sanya_123]

Цитата:

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

А какая версия была? Сколько пользователей?
Есть еще проблема - плохо сконфигурированный SQL сервер как в настройках так и в железе. У него возникает проблема распределения собственных ресурсов, что в навижине отражается как блокировка сессии пользоваля этой же сессией.

Можете дать рекомендации (или ссылку на них) по настройке SQL?
Чем там можно "поиграть" ?

У нас как раз очень часто возникают такие случаи -сессия блокирует сама себя.
При этом все начинает тормозить, резко растет нагрузка на диски.

[Dzemon]

Как выяснилось, это связано с нехваткой места для TempDB. Попробуйте обеспечить, улучшить, расширить ;-)

[Alterant]

Цитата:

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

3. Обмен с ЦО. Ну тут менеджеры требуют ВСЮ информацию из магазинов, а это немало! Если каналы связи хреновые, то могу Вам посочувствовать. Тут либо оптимизировать передаваемую информацию, либо широкие каналы. Это основная проблема.

Для решения этой проблемы у нас (IBS) есть решение, построенное на базе функционала репликации Landsteinar - пакетная репликация. К тому же оно делает возможным обмен данными, когда online впринципе не возможен, например, через внешний носитель.
Данные выгружаются в файл, передаются на удаленный хост (транспорт любой - FTP, e-mail, флешка ) и там загружаются. Перед передачей пакеты могут автоматически упаковываться RAR'ом.

[mazzy]

Цитата:

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

есть решение...

Ой, а давайте коммерческие предложения сюда
Коммерческие предложения

По теме еще что-нибудь будет?