Cпец.условия MS при миграции с NAV на AX

[artkashin]

Цитата:

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

1. почему не NAV ? - потому что по новым требованиям мне нужно будет вести детализированный учет продаж страховых продуктов, а это порядка 300 000 000 проводок в год. ну или всего 1 000 000 в день.

а сейчас это в разы меньше?
а планируется 1 000 000 в день в одной фирме?

А в чем собственно страх большого количества проводок - в том что пользователи будут "тупить" при учете? Ну так это то как раз решаемые проблемы, на мой взгляд. Тут, конечно, миллион ньюансов, но все же.
Просто если фирм сто, то делать в каждой 10000 проводок- это легко)))

Тут как раз тот факт, что для каждой фирмы NAV делает свой пул таблиц - это же генеральный плюс)

[rmv]

Цитата:

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

1. почему не NAV ? - потому что по новым требованиям мне нужно будет вести детализированный учет продаж страховых продуктов, а это порядка 300 000 000 проводок в год. ну или всего 1 000 000 в день.

Или 14 проводок в секунду, при условии что продакш база и фирма одна... Она действительно одна?

[alexb_imported]

Цитата:

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

Что будет, если на NAV Application Server подключится 1000 пользователей, да в одну фирму?

Даёшь каждому пользователю свой индивидуальный NAV Service Tier!

[artkashin]

Цитата:

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

Никогда не встречал в Навике, чтобы, например, заказ продажи из 30 строк учитывался у пользователя за 1 секунду. И это с учётом, что планируется, что остальные 1000 пользователей в базе ещё будут сидеть и чего-то делать. Пользователи уверен что в регионах сидят, компания же распределена по всей России.

Либо ошибка в расчетах, либо какая-то хитрая IT-структура должна быть, либо Аксапта волшебная.

ну .. я тоже не встречал 1000 пользователей в одной фирме)
а вот 100-150 в одной - это нормально, даже на среднестатическом железе
Соответственно, фирмы в NAV - это практический такой путь шардинга больших нагрузок.. Десять фирм 1000 пользователей потянут.. и будут они учитывать 10-ром одновременно и безболезнено, и тут уже будет по сути десятикратный рост.
а вечерком средствами скуля переносить это все либо в отдельную базу, либо даже в общую глобальную фирму.
а если подразделений под сотню, то вообще класс))

[sanya_123]

Цитата:

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

Цитата:

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

1. почему не NAV ? - потому что по новым требованиям мне нужно будет вести детализированный учет продаж страховых продуктов, а это порядка 300 000 000 проводок в год. ну или всего 1 000 000 в день.

А есть уверенность, что AX потянет такой объем? NAV последней версии по архитектуре очень напоминает AX. Если не брать в расчет рассказы маркетологов, что NAV для маленьких компаний, а AX для больших, то в чем технологическое преимущестов AX? Почему AX может обработать 1 млн проводок в день, а NAV не может.

отвечаем....
1. Сейчас у нас начинка NAV от версии 3.60 на классическом "толстом" клиенте NAV 2009 r2. переход на NAV 2013 - по трудозатратам не сильно отличается от перехода на AX.
технологическая разница между старым NAV и новым AX имеется. хотя и не в 100500 раз.

2. Уверенность может быть только в том, что видел сам. или видел тот, кому ты доверяешь). надеюсь, что референсы и общение пройдут удачно.

[sanya_123]

Цитата:

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

Цитата:

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

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

Дык, никто и не спорит, что можно поступить так. Да ещё и файловыми группами таблицы растащить по разным хардам. Летать будет! А ночью мерджить.

А можно пойти по пути LS Retail, отдельную небольшу таблицу транзакций юзеров за день только сохранять, а весь реальный учёт вести ночью через аналог "Оперативного отчёта".

А можно вообще на стандартную логику забить и использовать как платформу для разработки своей.
Для процессора или скуля 30 операций в секунду учесть - вообще плевок.

Цитата:

а если подразделений под сотню, то вообще класс))

Это все понятно.

Вопрос только, почему они так не делают?
Почему не масштабируют свою существующую и РАБОТАЮЩУЮ архитектуру дополнительными фирмами или серверами? Почему не хотят соединить 2-3 Навика, а хотят одну новую Аксапту?

Ответ для меня лично очевиден.
Только он лежит не в плоскости скорости программного или аппаратного обеспечения.
Обсуждать и выяснять истинные причины внедрения - означает предать себя окончательной анафеме на этом форуме. Яша и так уже негодуэ от оффтопика />

ЗЫ: Но можем и обсудить, разумеется. Не вопрос даже. Начинайте - я подключусь />
Только начинайте с ПРАВИЛЬНЫХ вопросов!

Идеальное заблуждение!

ситуация с технической точки зрения исчерпывающе изложена выше, в этой ветке.

по прочим причинам, кроме чисто технических - я считаю, что будущее за AX. А не за NAV. К сожалению. так сложилось, логично что флагман должен быть один.
Это не значит, конечно, что NAV загнется завтра. Платформа будет кое-как развиваться еще 3-4 года и поддерживаться еще лет 10. Вон, "Конкорд XAL" до сих пор жив, даже в России.
а потом будет слияние и миграция на какую нибудь "Ax Lite"
Ну и зачем вкладывать деньги и время в развитие платформы, которая скоро всё?

PS есть еще и психиатрические причины. ну это вы, jopagames3, тихо сам с собою. Я вам не доктор.

[rmv]

Цитата:

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

отвечаем....
1. Сейчас у нас начинка NAV от версии 3.60 на классическом "толстом" клиенте NAV 2009 r2. переход на NAV 2013 - по трудозатратам не сильно отличается от перехода на AX.
технологическая разница между старым NAV и новым AX имеется. хотя и не в 100500 раз.

2. Уверенность может быть только в том, что видел сам. или видел тот, кому ты доверяешь). надеюсь, что референсы и общение пройдут удачно.

Хм. Похоже у Вас крутится решение от компании на 3 буквы СОФТ, если это так - то да, наверно проще выкинуть лучшее перейдя на новую версию платформы.
Впрочем 1 млн. проводок в день - не такой уж большой объем для бэк-офиса даже для Нава.

[artkashin]

Цитата:

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

Хм. Похоже у Вас крутится решение от компании на 3 буквы СОФТ, если это так - то да, наверно проще выкинуть лучшее перейдя на новую версию платформы.
Впрочем 1 млн. проводок в день - не такой уж большой объем для бэк-офиса даже для Нава.

ну мы щас доиграемся, что NAV - это Highload система))))
У меня, вот есть видео-ролик древних годов, где паренек на русском-английском (с характерным R) демонстрирует пример нагрузочного тестирования, где в NAV продажи без блокировок идут (Порядка 30-ти сессий постят Sales Header c товарами/ресурсами/Фин.счетами в GL параллельно. Единственный пример в жизни, где я видел почти 100% загрузку винтов и процессора на сервере от NAV).
В подобном решении я думаю, даже 10 миллионов проводок в день - фигня вопрос - блокировок то , по сути, нет - ограничения в железе.
Вот только,
а) это ни фига не стандарт
б) подводных камней у этого чуда решения должно быть не меньше, чем в решении с шардингом подразделений по отдельным фирмам.