Здравствуйте, есть пять магазинов в городе они работают в УТ 11, проходят часовые обмены. Руководство не устраивает данный способ, хотят перевести всех в одну базу. Думаем использовать тонкий клиент, подскажите какая ширина канала необходима для работы в тонком клиенте. и какие подводные камни могут возникнуть. Спасибо.

>и какие подводные камни могут возникнуть
нет интернета, нет продаж

а еще - плохой интернет, плохие продажи.

(0) А чего именно не устраивает?
А так да см (1)

встала одна база - встали _все_ точки продаж.

Запили 5-ти минутные обмены.

Сделать чтобы обмены были минутными. Что за мега торговые центры, что обмены часовые?

(6) Думаю, имеются ввиду, что обмен каждый час.

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

(8) потому, что не в канале дело. Если епических печатных форм и отчетов не генерить, то для продажи хватит и ЖПРСа.
Замес в том, что ширина канала - самая мелкая из проблем

(8) Пациент приходит к хирургу.
- Доктор, сделайте мне пожалуйста кастрацию.
- Да вы что?
- Доктор, я вас очень прошу. Мне очень надо.
После операции хирург обращается к пациенту:
- Зачем вы это сделали? Вы такой молодой, красивый мужчина, в полном расцвете сил. У вас вся жизнь впереди, у вас могло быть столько женщин. Скажите мне, зачем вам это было нужно?
- Видите ли доктор, я женился на еврейке, а у них такой обычай.
- Так может быть вам надо было сделать обрезание?
- А я вам что сказал?
©

на магазин 10 мбит и пинг < 50мс теоретически будут работать главное в магазинах ютубики в ХД сильно не смотреть и торренты не качать

но (1) пересиливает все

(12) если б только в интернете дело... его и зарезервировать можно достаточно дешево...
А вот резервировать хорошо нагружаемые сервера - достаточно дорого...

(12) (1) Допустим, кассовое ПО стоит отдельно. Какие камни именно в торговле?
(9) >>Если епических печатных форм и отчетов не генерить.
В типовой УТ запрос расчета скидок 8000 строк. он попадает под  ваше определение?

(14)  "Какие камни именно в торговле?"
- Посмотрите, вот артикул детали, есть у вас такая?
- Извините, программа не работает, не могу посмотреть.

(7) а зачем каждый час обмен? Что за оперативность? В центральной базе хотят онлайн продажи смотреть?

(16) Да я хз, я ж не руководство этой сети ))))

(13) на пять магазинов (условно 25 рабочих мест) - не очень дорого. но вопрос, зачем такая оперативность. может можно решить другими методами.

В магазинах есть как розничные аппараты так и оптовые продажи, в крупном 25 человек остальные среднечки на 10-15 пользователей. Оперативность требуется чтобы в магазины могли оперативно сделать заявку на центральный склад, так же оперативное согласование по выписывающимся счетам и остатки других магазинов. Центральный склад уже работает в базе одного из магазинов.

И у нас на центральный сервак идет 4Mb канал VPN через который планируется подключать порядка 80 человек.

(20) ставьте 2 базы - тонкий для оперативного и как было - для розницы. Нет инета - не пашет оперативная, а на рознице обмен не так часто.

Про интернет думаем про резервные каналы, поставить свистки(жпрс). Либо оставить базы данных так же на серваках разовыми с ночными обменами, в случае пропажи интернета можно было перекинуть на локальную копию.

(20) А что директор магазина разве не сам делает заявки на склад? Или теперь это за него будут делать из гл офиса? А зачем это?

Сам делает и склад их хочет сразу видеть.

(25) Для этого общая база не нужна в принципе. Наладь ЭДО и все

(23) Едрить, вы хитрые идальги.
А что с остатками делать в этих ночных копиях, когда пользователи на них переключаются? Они ж будут совсем не те, что были до переключения

+(27) и что делать, если интернет пропал в 12 по полудни, а в 15:47 опять появился?

(27) а их днем синхрить с ЦБ. своего рода распределенка с обратным обменом.

(29) и чем это отличается от "сделать существующий обмен раз в пять минут"?

+(30) кроме того, что сделат обмен чаще проще, быстрее и надежнее

Если мы хотим иметь реальные остатки, то они ведутся в каждой базе магазина отдельно, но при изменении передаются в отдельную центральную базу, где их могут посмотреть другие магазины - передача идёт как можно быстрее после проведения документа.
При этом, в каждом магазине остатки всегда верные и интернет (точнее его отсутствие) на них не влияет, а в центральной базе мы видим актуальные остатки только тех, кто подключен к интернету - соответственно, передача между магазинами регистрируется в центральной базе, но сначала выполняется в базе магазина, из которого доставляется товар, чтобы не уйти в минус.
Создание нового товара также - сначала в центральной базе, а потом "возвращение" в локальную базу и все остальные, так как в других магазинах он тоже может появится.

У нас такая схема 7.7 еще в 2010 году работала на ISDN модемах (это времена до ADSL). Ничего работала. В магазинах тонкие клиенты которые конектятся по РДП на единный сервак

(20) 10 человек и все розница?
Я бы на розницу оставил базу РИБ, а опт и кто заявки делает в тонкий клиент сделал.

(34) +100
Для магазинов распределенная база - идеальный вариант.

Если надо что-то срочно посмотреть или сделать заявку в центральной базе - сделайте RDP оптовому менеджеру до сервера центрального офиса или тонкий клиент.

(33)
В одной из бывших фирм так вообще по модему с помощью проги PCAnyWhere  обмен в РИБ 7.7 делали ))

Если стоят фискальники на точках, то будет затраивать продажа через тонкий клиент, при глюке интернета.

Бредовая идея. На старой работе все работали в одной базе, 1-2 раза в год в каком-нибудь филиале пропадал интернет и они сидели и ждали когда он появится. А если клиент приехал с области и не хочет снова приезжать в другое время? Отношения с ним испортятся.

+ (38) потом все филиалы перевели на РИБ.

(1) это скоро будет реализовано   онлайн  кассами  с  2017го года

(40) Реализовано что?)))

при наличии интернета все прекрасно работает через RDP
использовал следующие ПО

Далион ПРО
на кассах Frontol (загружается через ftp или dropbox)
весы Масса-К (так как есть удобная загрузка через текстовый файл единственный неудобный момент, соответственно переписан слегка модуль выгрузки в весы)
(алкоголь тоже решен т.е. один ключ на магазине и обратный проброс с VPN из офиса когда товаровед работает с алкоголем)

Ну и вообще то РИБ удобней так как пришлось сильно покататься в провах чтоб магазины не смотрели выручки друг друга и так далее

но отказались от РИБ только по одной причине это ведение единого справочника товаров и экономии на закупках 1с (каждая точка -40деревяных).

последний аргумент в -40руб по большому счету не самый важный

(23) Все правильно думаете.
(27) Да плевать на остатки. Главное что бы точка не стояла и товар продавался.
У нас примерно так же сделано. В магазине сервер стоит к клиентских ПК где то штук 10 подключено. Каждую ночь генерируется спец база, по сути срез текущей но только точ то нужно для продажи (номенклатура, цены). Раскидывается эта база по кассам.
В случае падения базы магазина, или других проблем с серваком, кассиры переключаются на локальную. Там можно только продать (нельзя оформить доставок, заказов. Только чеки). Главное что бы магазин не стоял.