Одно меню на 5 точек.

[nekrasov]

Для локальных отчетов вам понадобится repsserv.ini приложение отвечающее за Локальные отчеты rkReportsServer.
Сейчас у вас кассы midservera завязаны с центром ref сервером,чтобы были отчеты заводите в манагере Настройки - Сервер отчетов. Создаете Локальный новый rep1(и таких столько сколько у вас локальных точек).
на локальном ресторане разворачиваете sql, в repsserv.ini
Client = "rep1" локальный rep
RefServer = "RK7SRV" ваш центральный ref
в самом низу
[TCPSOC]PORT=3640 (тот порт на котором работает локальный rep на этот порт кассовые сервера и отдают локальыне данные)
[TCPDNS]
RK7SRV=Статический адрес центрального ref:Порт который указан в ref по умолчанию 3639

запускайте rkReportsServer(лучше десктопом) , лицензируете отчеты, запускате если запустился(синий куб), цепляете кассы к нему в rkipper.ini RefServer = rep1 и [TCPDNS]
rep1=ip где крутиться локальный rep:3640(rep в примере на 3640)
Останется подключится манагером к локальному rep будет доступен для просмотра и сделать экспорт в Локальный sql настроив предварительно sql подключение.
это схема центральный ref(не лицензирован так как отчеты смотрят в ЦОrep) - и 4 локальных rep1,rep2...Идея думаю понятна.

P.S. Для централизации у себя делал отдельный Центральный REP для касс отчетов(лицензирован) и отдельный REF для заведения (меню, персонала) разгрузки так сказать.

ЦО.jpg
При такой схеме нужно делать 2 ярлыка один на лок отчеты второй на редакторЦО и если ref не лицензирован кубы свои сделать не получится, разделять их или нет Ваш выбор

[nekrasov]

Teamviewer есть

Поддерживаю, Лицензия себя оправдывает. никаких нареканий тимка не вызывает. учетку делаете заводите там компы с вбитыми паролями видите где есть интернет где нет, с телефона есть приложение тимки в личный кабинет и видите кто доступен кто нет, при необходимости можно подключиться с телефона. с rdp такого не получится без статических адресов на локальных точках. vpn смысла большого не вижу.

[mcmaster]

Как быть с лицензированием? Ключи на ref на локальных машинах на точках.

[nekrasov]

меню в одном месте заводите сейчас?
PS кстати тут repsserv.ini тоже указываете параметр UseSQL=
По поводу лицензирования не подскажу запустите старый локальный ref скопируйте оттуда саму лицензию.Остановите полностью старый локальный ref(если не используется)запустите rkReportsServer с подключением к ЦО и параметром UseSQL=0. Из локального ресторана(там где rkReportsServer) запустите манагер который подключается к ЦО по статике в Настройках сервера отчетов для локального ресторана выберите ключ старого локального ref снять запрос и вбейте лицензию которую копировали, если встанет она, желайте настройку подключения к локальному sql(там своя строка подключения можно сделать универсальную если не по имени подключатся а по ip 127.0.0.1,1433 к примеру)

[mcmaster]

меню в одном месте заводите сейчас?

5 ресторанов, на одном из них поднял сервер справочников и подключил к нему все кассовые сервера. Раньше всё было локально - 1 ресторан 3 - 4 кассовых сервера - 1 сервер справочников/отчетов.
Меню и персонал заводят в одном месте теперь.
Менеджеры на точках надо новые сделать? Подключать их к единому серверу справочников? На основном создавать сервера отчётов для каждой точки? На точках поднимать свои SQL сервера и rkRepotServerа? Лицензировать их в основном ресторане...
Запутался в общем(

[nekrasov]

На основном создавать сервера отчётов для каждой точки?

Если вы имеете ввиду Настройки - Сервера отчетов создать новый для локали то да.

Менеджеры на точках надо новые сделать?

Если развернете rkRepotServerа то и подключать локальных менеджеров к нему (для просмотра локальных отчетов)

На точках поднимать свои SQL сервера и rkRepotServerа?

Да

Лицензировать их в основном ресторане...

да

В вашей схеме есть нюанс у вас Сервер справочников ЦО(там где правят общее меню) является и Сервером ЦО отчетов он будет нагружен!
Скорей всего вам порекомендуют их разделить дополнительным Центральным rkRepotServerа Локальные rkRepotServerа к нему завязаны
Ключ лицензии нужен только там где пересчитываются кубы
Уффф...

[mcmaster]

Буду пробовать, спасибо!

[lEEFT]

Извините, если повторюсь - много постов перечитывать...

Есть 2 схемы:
1) уверены в интернете и все сервера на одном сервере
2) на каждом объекте свой сервер отчетов

Более отказоустойчивый вариант 2. Реализация такая:
Центральный сервер справочников, центральный сервер отчетов
на объекте поднимается сервер отчетов со своей базой и настройками на обработку смен и пересчета кубов. Ключик физически там, где запущен сервер. Локальный СО цепляется к центральному северу отчетов, кассы цепляются к локальному серверу отчетов. Менеджерские станции коннектятся к локальному серверу отчетов.
Плюсы: Построение отчетов и списание с СХ не зависят от канала связи с центральным сервером.
Минусы: ключ сервера отчетов


1й вариант:
ЦО справочники, ЦО отчеты, локальные сервера отчетов объектов (без обработки данных и кубов, один номер ключа с ЦО отчетов, только без лицензии) на одном сервере. Кассы цепляются через канал связи к своему СО. Менеджерские части подключаются к ЦО, но разграничены правами по объектам. В СХ настроен номер ресторана для выгрузки
Плюсы: один ключ сервера отчетов, лицензируется только ЦО отчетов.
Минусы: Отчеты и списание зависят от наличия связи с центром, разучить пересчитывать кубы персонал и заниматься этим самому.
доп инфо: http://www.carbis.ru/forum/Инструкци...�етов.html


В любом случае для изменений из редактора потребуется связь с ЦО.

У меня из 22 объектов 5-7 работают по первому варианту, проблем нет.

---------- Добавлено в 13:44 ---------- Предыдущее сообщение было размещено в 13:41 ----------

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

Не совсем так. Ключ нужен там, где запускается сервер отчетов, и его номер должен быть прописан в справочнике. А вот ЛИЦЕНЗИЯ открывает доступ к построению кубов.

[alkon132]

Насчет отказоустойчивости второго варианта (с локальными серверами отчетов) поспорю.
Надежность системы считается как произведение надежности каждого компонента.
Для упрощения - есть у нас кассовый сервер, локальный сервер отчетов, центральный сервер отчетов, сервер справочников. Надежность каждого - условно 90%.
Общая надежность системы = 0,9*0,9*0,9*0,9 = 66%

Для варианта рефсервер-кассовые сервера надежность будет 0,9*0,9 = 81%

Это теория, но практика на больших сетевых объектах эту теорию подтверждает. Имеет место быть проблема с неправильной синхронизацией справочников на локальных серверах отчетов. К слову, по слухам механизм этой синхронизации перерабатывается и проблема должна уйти в будущих версиях.

Итого мои выводы такие:
Для малых и средних сетей предпочтителен вариант 1 (без локальных серверов отчетов). Кроме прочего, это экономия на серверном ПК в самих ресторанах (не всегда, но часто он там не нужен).
Для больших нагруженных сетей - полноценный второй вариант.

[lEEFT]

Надежность имеется ввиду в том, что работа точки не тормозиться при отсутствии интернета. Склад списывает дальше, ведется контроль продуктов, можно в любой момент сделать инвентаризацию и т.д. С этой же точки зрения и ставят в фаст-фудах кассовый сервер на саму кассу, а не один сервер для 3-5-10 станций.

Такой совет в свое время дала компания UCS:
Если более 10 локальных СО в справочнике, то нужно делать транзитные сервера для разбития потока передачи данных и как следствие повышение качества переданного.

Реально на практике было около 20 СО, которые цеплялись к центральному СО. Имели место падения лицензий, отсутствие обновление словарей и прочих шалостей. После разбивки через транзитные сервера проблемы ушли.

Суть такова, что контроль передачи данных 7 файлов идет стабильней, чем 20. Хотя с точки зрения протокола TCP/IP мне этого не понять. Может они по UDP передают обновления?

---------- Добавлено в 14:22 ---------- Предыдущее сообщение было размещено в 14:19 ----------

Итого мои выводы такие:
Для малых и средних сетей предпочтителен вариант 1 (без локальных серверов отчетов). Кроме прочего, это экономия на серверном ПК в самих ресторанах (не всегда, но часто он там не нужен).
Для больших нагруженных сетей - полноценный второй вариант.

Я бы не стал давать такой совет, т.к. тут нужно выбирать бизнесу.