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

Проблема может быть технической или пользовательской. Чтобы это определить, нужно в первую очередь воспользоваться кнопкой «Невидимые объекты» (может называться «Невидимые элементы»).

Пользовательская проблема

Для примера: было создано новое блюдо меню «Кофе» в папке «Бар», которое не появляется на кассе. Мы на кассе переходим в папку «Бар», не видим там «Кофе», находим в интерфейсе кнопку «Невидимые объекты» (она может быть под кнопкой ДОП),

нажимаем и видим элементы меню, которые не отображаются по некоторой причине, записанной в названии кнопки под звездочками. Предположим, что для нашего «Кофе» написано «**Не задана цена**».

Это значит, что у блюда нет цены – данная проблема не техническая, нужно исправить настройки блюда. То же самое может касаться скидок или валют. Всегда проверяем через «Невидимые объекты».

Техническая проблема

Если мы видим, что комментарий к элементу в режиме просмотра Невидимых объектов не соответствует действительности (например, написано «цена не задана», хотя она точно задана), или искомого элемента нет как в «видимых», так и в «невидимых», значит это техническая проблема синхронизации.

Статус синхронизации всегда можно проверить прямо на кассе, нажав в окне регистрации (самое начальное окно РК-касса) надпись R-keeper или кнопку в виде лампы. Появится окно тех. информации. В левом нижнем углу возможны надписи: Синхронизация выполняется; Синхронизация: нет связи

Возможные причины отсутствия синхронизации

1. Нарушена связь с сервером верхнего уровня (СВУ)

2. Синхронизация отключена в справочниках

3. Произошел сбой синхронизации, так называемый "рассинхрон"

Нарушена связь с сервером верхнего уровня

Нужно проверить связь КС с сервером верхнего уровня. Для этого запустить midserv.exe десктопом и посмотреть в окне "Станции" присутствует ли имя сервера верхнего уровня (это имя фигурирует в rkeeper.ini в параметре RefServer)

Если связи с СВУ нет, ее нужно восстановить. Подробнее в статье.

Восстановление связи с сервером верхнего уровня

Синхронизация отключена в справочниках

Нужно проверить включена ли синхронизация с кассовым сервером в Справочниках.

Сбой синхронизации "рассинхрон"

Если при нажатии на кассе на надпись R-Kepper вы видите статус Синхронизация выполняется, связь КС с СВУ установлена и синхронизации не отключена в справочниках, но изменения на кассу не приходят, - значит вы имеете ситуацию рассинхрона, которая чаще встречается в крупных сетях с многоуровневой структурой серверов, но в одноуровневых тоже бывает.

Для устранения рассинхрона нужно выполнить принудительную синхронизацию Кассового сервера с Сервером справочников. Ниже описана логика и виды такой синхронизации.

*Следующее описание будет касаться старого типа синхронизации, который мы используем почти везде с отключением Dbsync. Для новой синхронизации некоторые моменты будут отличаться.

Краткий ликбез по структуре синхронизации

Все данные справочников RK7 и производимые в них изменения записываются во внутренние таблицы, находящиеся в базе данных в файле RK7.udb, с которым работает сервер справочников REFSERVER. Кассовый сервер (MIDSERVER) в онлайн режиме связывается с REFSERVER, получает от него данные из этой базы и записывает в свою «рабочую» базу данных, состоящую из файла WORK.UDB и множества вспомогательных файлов в папке MIDBASE.

Данные непосредственно справочников (блюда, валюты, скидки, работники, станции и т.д.) содержатся внутри MIDBASE в папках с названием Col***. Это «коллекции».

Данные по внутренним драйверам устройств (фискальники, принтеры, весы, банк терминалы) содержаться также в папке MIDBASE в файлах с названием MODULES, основным из которых является modules.udb. Это модули.

Связь между MID и REF сервером может быть одноуровневой или многоуровневой. В первом случае MID обращается непосредственно к REF (большинство одиночных ресторанов и небольшие сети, например, Дюшес).

Во втором случае, характерном для сетевых клиентов, между MID и REF существуют транзитные (промежуточные) сервера: для двух уровней это связка REF-REP-MID (сеть БИКО); для трех уровней возможны разные связки: REF-RET-REP-MID (KFC); REF-REP-RET-MID (КофеПорт, МаксБейкери); REF-REPcentral -RET-REPlocal -MID (Урюк); .REF-REPcentral -REPgroup-MID (Тарас Бульба)

Отличие REP от RET состоит в том, что REP это транзит с базой отчетов SQL, то есть на нем можно смотреть отчеты, в остальном с точки зрения логики синхронизации между ними нет разницы, важно только какой уровень в иерархии передачи данных занимает тот или другой.

В случае многоуровневой конфигурации REF-REP-MID синхронизация происходит с использованием базы транзитного сервера REP или RET, которая хранится в файле refsdata.udb по пути, заданному в конфигурационном файле repsserv.ini в параметре RefsBasePath

Ниже представлены блок-схемы для разных конфигураций.

REF-REP-MID (БИКО)

REF-REP-MID

В случае REF-REP-RET-MID синхронизация происходит с использованием сначала базы транзитного сервера первого уровня REP, которая хранится в файле refsdata.udb, а потом транзита второго уровня RET, база которого хранится в его собственном файле refsdata.udb Схема аналогичная и пути к базам находятся в одноименных файлах repsserv.ini.

REF-REP-RET-MID (Макс Бейкери и Кофе Порт)

REF-REP-RET-MID

REF-REPcentral -REPgroup-MID (Тарас Бульба)

REF-REPcentral -RET-REPlocal-MID (Урюк)

Одноуровневая принудительная синхронизация (Перекачка MIDBASE)

Если между MID и REF транзитные сервера (REP и RET) отсутствуют, то синхронизация выполняется с помощью перекачка папки MIDBASE. Перекачка может выполняться с модулями или без. Если проблема касается справочников меню, скидки, персонал, валюты, то модули перекачивать не нужно, т.к. это занимает много времени; если проблема касается устройств или вы не знаете чего именно, то можно перекачать с модулями.

Перекачка с модулями

Определить, где расположена папка MIDBASE: в RKEEPER.ini параметр BasePath
Остановить процесс midserv.exe. Выделить в папке MIDBASE все файлы и папки клавишами CTRL+A, затем снять выделение CTRL+ЛКМ со следующих файлов и папок: Archive; Backup; Forsend; Work.udb (то есть должно быть выделено все, кроме этих четырех); удалить в корзину всё выделенное. Никогда не удаляйте через Shift!
Запустить midserver и ждать, пока не подкачаются все удаленные файлы и папки в MIDBASE. Дольше всех будет закачиваться файл MODULES.udb, по окончании закачки его размер должен стать примерно равным удаленному в корзину. Также, можно наблюдать за загрузкой CPU у процесса midserv.exe – если он перестал грузить CPU, значит перекачка завершилась.
Запустить кассу и проверить.

Перекачка без модулей

Все то же самое, только в папке MIDBASE нужно оставить еще и файлы modules.* Таким образом, остаются: Archive; Backup; Forsend; Work.udb; modules.udb; modules.tmp; modules.bak остальное удаляется в корзину.

Двухуровневая принудительная синхронизация REF-REP-MID

Если между REF и MID присутствует транзитный сервер REP, то перекачки MIDBASE может оказаться недостаточно, т.к. сбой синхронизации мог произойти на уровне этого транзитного сервера REP.

Как определить есть ли транзитный сервер.

Большинство крупных сетей имеют транзитные сервера, а отдельные рестораны или малые сети нет.
Спросить у старшего
В конфиге кассового сервера rkeeper.ini посмотреть значение параметра RefServer, которое содержит имя сервера верхнего уровня, и, если в этом имени содержится "REP" или "RET", то значит кассовый сервер общается не с REF-ом а с промежуточным REP-ом (или RET-ом)

Синхронизация по этому типу включает два этапа:

Перекачка базы REP refsdata.udb

Найти, где работает REP server, к которому обращается наш MID. Для этого нужно подключиться к центральному серверу сети и найти службу или процесс в имени которого будет фигурировать имя нашего REP сервера, которое мы узнали из rkeeper.ini

Но REP может работать и на локальном сервере ресторана, это можно определить также по rkeeper.ini смотри адрес в параметре в секции [TCPDNS]

Пройти в папку, откуда запускается исполняемый файл РЕП-сервера.
Из файла repsserv.ini параметр RefsBasePath выяснить путь к refsdata.udb
Пройти по этому пути
Остановить процесс или службу нашего REP сервера
Запомнить размер файла refsdata.udb, после чего удалить его в корзину
Запустить REP службой или десктопом и ждать пока не перекачается удаленный файл refsdata.udb; наблюдать за этим можно, сравнивая его размер с размером удаленного: он должен стать примерно таким же.

Перекачка MIDBASE при необходимости

Если после перекачки Resdata.udb, проблема осталась, то стоит перекачать и MIDBASE с модулями или без. Смотри выше.

Трехуровневая принудительная синхронизация REF-REP-RET-MID

Из трехуровневой разберем только этот тип, все остальные, перечисленные выше, перекачиваются совершенно аналогичным образом: неважно REP или RET - главное какой выше какой ниже, и у всех перекачиваем refsdata

Принцип тот же самый, но включает перекачку сначала refsdata.udb, принадлежащего серверу REP, выполняющего роль транзита первого уровня, а потом refsdata.udb, принадлежащего серверу RET - транзита второго уровня. Таким образом, перекачка происходит СВЕРХУ-ВНИЗ: сначала качаем первый уровень это REP, потом второй - RET, потом уже коллекции MID.

Перекачка базы REP (первый уровень) refsdata.udb

Определить с каким сервером верхнего уровня (в нашей конфигурации это RET) работает наш MID
Определить машину, на которой работает RET; пройти в папку откуда он запускается
Определить имя сервера верхнего уровня (REP), с которым работает наш RET. Параметр RefServer в repsserv.ini
Определить на какой машине работает REP; найти его службу или процесс
Пройти в папку откуда он запускается и в файле repsserv.ini найти путь к базе refsdata.udb
Перекачать refsdata.udb (процедура описана выше)

Перекачка базы RET (второй уровень) refsdata.udb

Вернуться к нашему RET серверу и тоже перекачать refsdata.udb *** Нельзя перекачивать их параллельно: сначала перекачиваем refsdata для RET, а потом для REP, дожидаясь окончания предыдущей операции.

Перекачка MIDBASE

Вернуться к нашему MID серверу и при необходимости (если изменения на кассе не произошли) перекачать MIDBASE.

Связанные статьи и полезные ссылки