Оценка жизнеспособности предложенного решения

[gega]

Бизнес процессы в общих чертах следующие.
Компания занимается розничными продажами. Около 200 наименований продуктов. Порядка 15 филиалов в разных регионах (странах). У филиалов есть как бы подфилиалы, подчиненные филиалам, т.е. вобщем получается древовидная структура (всего около 150 единиц). Покупатели постоянные, т.е. чтобы стать покупателем нужно предварительно зарегитрироваться и получить идентификатор (на данный момент около 100 тысяч покупателей). Идентификатор единый для всех филиалов. По итогам месяца покупателям предоставляются различные скидки.

Решено реализовать учет с использованием MS NAV. Разработчики предложили следующую схему развертывания: все работают в стандартном интерфейсе NAV на терминальном сервере.

У меня следующие вопроы:
1. насколько жизнеспособно это решение с точки зрения производительности? В основном вводятся заказы. Сейчас в пиковые дни вводится около 5000 заказов. Для реализации бизнес логики расчета скидок при вводе заказа кроме блокировки стандартных таблиц блокируются еще несколько специально созданных. Не будет ли время ожидания учета заказа слишком большим при одновременной работе 10-15 филиалов одновременно? А в дальнейшем, например, 20-25-50?
2. насколько рационально использовать стандартную форму ввода заказа в точке продажи (POS)? Например, нет горячих клавиш для вызова часто используемых функций. Или чтобы обновить статистику по заказу при вводе строк, нужно щелкнуть мышкой по заголовку. Точка продажи не подразумевает оплату. Выписывается только заказ, который оплачивается в кассе.

Если нужны уточнения или какие-то дополнительные сведения, готов предоставить.

Заранее всем спасибо за комментарии.

[Fordewind]

В принципе вполне жизнеспособно.

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

Еще бы хорошо протестировать каналы связи до начала работ. Понятно, что при такой работе длительные ОБРЫВЫ не допустимы.

Если будут вопросы обращайтесь

P.S. Если не секрет, что за 200 позиций пользующихся таким бешенным спросом? ))

[gega]

Fordewind, спасибо за ответ.

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

Понятие "ночью" практически неприминимо. Филиалы есть в разных часовых поясах. Например, во Владивостоке, в Новой Зеландии, в Европе. Да и учитывать надо сразу после продажи, чтобы обновлять информацию об использованных скидках и наличии товара на складе. И еще я заметил, что при большом пакетном учете заказов (мы импортировали имеющиеся заказы из старой системы) сервер просто висит, то есть кроме процесса, который учитывает, никто работать не может.

РАЗРЫВЫ в каналах связи будут. Для этого предусмотрен временный офлайновый ввод с последующим импортом в NAV.

Уже, к сожалению, обратились. Больше года разрабатывают...

P.S. Почитайте про сетевой маркетинг (многоуровневый маркетинг, MLM, прямые продажи). Позиций с таким спросом может быть гораздо меньше.

[Fordewind]

Где-то на форуме был похожий вопрос. С филиалами и множеством операций. Может уже есть реализация.

С разными поясами конечно хуже. одновременный учет будет тормозить.

Кстати, а зачем вам все это держать в одной базе по всем филиалам? Почему не сделать несколько? В приведенной постановке противопоказаний не вижу.

[RedFox]

Цитата:

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

Бизнес процессы в общих чертах следующие.
Компания занимается розничными продажами. Около 200 наименований продуктов. Порядка 15 филиалов в разных регионах (странах). У филиалов есть как бы подфилиалы, подчиненные филиалам, т.е. вобщем получается древовидная структура (всего около 150 единиц). Покупатели постоянные, т.е. чтобы стать покупателем нужно предварительно зарегитрироваться и получить идентификатор (на данный момент около 100 тысяч покупателей). Идентификатор единый для всех филиалов. По итогам месяца покупателям предоставляются различные скидки.

Решено реализовать учет с использованием MS NAV. Разработчики предложили следующую схему развертывания: все работают в стандартном интерфейсе NAV на терминальном сервере.

У меня следующие вопроы:
1. насколько жизнеспособно это решение с точки зрения производительности? В основном вводятся заказы. Сейчас в пиковые дни вводится около 5000 заказов. Для реализации бизнес логики расчета скидок при вводе заказа кроме блокировки стандартных таблиц блокируются еще несколько специально созданных. Не будет ли время ожидания учета заказа слишком большим при одновременной работе 10-15 филиалов одновременно? А в дальнейшем, например, 20-25-50?

Делать только ввод и выпуск заказов (если слабенький сервер, а на нормально - это нормальный объем (хотя не указано кол-во строк в заказе!!!)). А ночью делать пакетный учет "продаж". Хотя я бы выбрал топологию типа звезда с пеплакацией данных.

Цитата:

2. насколько рационально использовать стандартную форму ввода заказа в точке продажи (POS)? Например, нет горячих клавиш для вызова часто используемых функций. Или чтобы обновить статистику по заказу при вводе строк, нужно щелкнуть мышкой по заголовку. Точка продажи не подразумевает оплату. Выписывается только заказ, который оплачивается в кассе.

Без проблем можно использовать, так как форма вполне нормальная и Эдолжна справиться" с объемом.