Несколько ресторанов в одном SH

[olegash]

Сеть из 2 ресторанов (будет 3). В каждом свой RK Менеджер и соответственно кассовый сервер со станциями. Меню одно и тоже на 99% (было загружено из RBO). Но в каждом из ресторанов есть небольшие изменения/дополнения. SH в одном из ресторанов. В нем созданы две корневые вершины для каждого ресторана. Созданы по 2 склада (бар и кухня) для каждого ресторана и центральный склад. В связи с этим несколько вопросов: 1. Т. к. поля Sifr и код блюда в меню R-Keeper-е ресторанов одинаковы, не будет-ли каких проблем при импорте меню и расхода из разных ресторанов и дальнейшего учета по разным складам? 2. Как организовать импорт данных из R-Keeper-ов через интернет (вернее один стоит локально на том же ПК, что и SH, а другой удаленно)? Желательно в автоматическом режиме (ну или с минимальным участием человека). 3. Доступ из 2-ого ресторана (заведение накладных) и центрального офиса (просмотр отчетов) надо организовать через доп. рабочие места SH? Там вроде все по TCP/IP-только порт пробросить? 4. Может правильней было и R-Keeper Менеджер поставить один и списывать на основе мест реализации (если я правильно понимаю как этот механизм работает)? 5. В дальнейшем планируется перевести еще 12 ресторанов этого РХ на RK и SH. Но меню во всех ресторанах (и Юр. лица) будут разные. Т. е. без SHBO уже не обойтись получается? Начальство хочет видеть отчеты по всем своим организациям в разных разрезах. Да и 7-ка вроде напрашивается. 6. Могу - ли я купить одну лицензию Sh на себя, сделать несколько серверов и баз (вроде на одном ключе можно), купить доп. рабочие места для каждого ресторана (9000 против 42000 р.) и организовать удаленную работу на своем сервере? А с RK менеджер тоже самое прокатит? На самом деле вопросов еще очень много, но хотелось бы начать с этих, а дальше продолжить (если вы не против, конечно).

[SH]

2. Как организовать импорт данных из R-Keeper-ов через интернет (вернее один стоит локально на том же ПК, что и SH, а другой удаленно)? Желательно в автоматическом режиме (ну или с минимальным участием человека)

Если нужны отчеты на локальной точке, то делаем батник, который при запуске закрытия дня (вручную или автоматически - не важно) копирует данные endday в другую папку. Далее используются программы облачной синхронизации, dropbox или sugarsync, которыми эти данные синхронизируются на удаленную машину. А там делается свое закрытие дня. Можно и файлик ark6.udb синхронизировать, но он тяжелый, что обычно неудобно.
В общем, получаем копию ark6.udb локально, папку db с меню также синхронизируем и можно делать импорт.

3. Доступ из 2-ого ресторана (заведение накладных) и центрального офиса (просмотр отчетов) надо организовать через доп. рабочие места SH? Там вроде все по TCP/IP-только порт пробросить?

Да.

4. Может правильней было и R-Keeper Менеджер поставить один и списывать на основе мест реализации (если я правильно понимаю как этот механизм работает)?

Только если есть необходимость смотреть общие отчеты R-Keeper.

5. В дальнейшем планируется перевести еще 12 ресторанов этого РХ на RK и SH. Но меню во всех ресторанах (и Юр. лица) будут разные. Т. е. без SHBO уже не обойтись получается? Начальство хочет видеть отчеты по всем своим организациям в разных разрезах. Да и 7-ка вроде напрашивается.

Да! Семерка тут явно напрашивается. Бэкофис RK6 вызывает у меня множество претензий. Бэк SH4 требует предельной сверхаккуратности.
Могу так сказать: есть много-много-много подводных камней при работе с бэкофисами. Особенно - с бэкофисом сторхауса. Я его готовить так и не научился, поэтому я его не полюбил. Бэкофис кипера нужен только при более-менее совпадении меню. В общем-то, тут еще и от проходимости в этих заведениях зависит, точнее, от количества чеков.

6. Могу - ли я купить одну лицензию Sh на себя, сделать несколько серверов и баз (вроде на одном ключе можно), купить доп. рабочие места для каждого ресторана (9000 против 42000 р.) и организовать удаленную работу на своем сервере?

С точки зрения возможности - да, с точки зрения законности - нет.

с RK менеджер тоже самое прокатит?

Не пробовал, что там будет при одновременной работе, но не вижу препятствий.

На самом деле вопросов еще очень много, но хотелось бы начать с этих

Что рекомендую.
Если сразу по уму, нужно: rk7, shbo и _одна_ база shouse. Начать так, потом по ходу станет понятно, что к чему.
Если rk7 не получается, то можно RKBO + единые отчеты.

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

(было загружено из RBO)

А этот RBO куда делся?

купить доп. рабочие места для каждого ресторана (9000 против 42000 р.)

При таком раскладе надо покупать столько доп.мест, сколько будет максимально сидеть одновременно сотрудников в _одной_ базе.
То есть, если у нас 15 ресторанов и 15 баз, но с каждой из баз работает максимум 4 человека, то надо 4 лицензии, 1 главная и 3 допа. Еще раз: это законно, только если у всех ресторанов один владелец. Тут за разъяснениями можно в центральный офис UCS обратиться. Но работать будет.

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

SH в одном из ресторанов. В нем созданы две корневые вершины для каждого ресторана. Созданы по 2 склада (бар и кухня) для каждого ресторана и центральный склад. В связи с этим несколько вопросов: 1. Т. к. поля Sifr и код блюда в меню R-Keeper-е ресторанов одинаковы, не будет-ли каких проблем при импорте меню и расхода из разных ресторанов и дальнейшего учета по разным складам?

Нет, проблем не будет. Схема хорошая, так и оставляйте. Пока база не будет очень жирной, проблем не будет.
Проблемы будут, когда база будет жирная Я тут недавно столкнулся, когда крупную сеть ресторанов ведут в одной базе, первый раз увидел, как тормозит Shouse4. Резка базы каждый год будет обязательна.
Поэтому я и рекомендую сразу садиться на SHBO. Потому что если потом разделите базы, общим отчетам придется сказать "прощай".

[olegash]

А на первый вопрос, если не сложно можно комментарий?

---------- Добавлено в 01:35 ---------- Предыдущее сообщение было размещено в 01:28 ----------

А этот RBO куда делся?

Это франшиза. Я не знаю насколько он используется в центральном офисе-мне прислали только файл .TDB. Я его загрузил и больше никаких настроек по синхронизации с ЦО не делал-по ходу его не особо используют, только для выгрузки меню.

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

Поэтому я и рекомендую сразу садиться на SHBO. Потому что если потом разделите базы, общим отчетам придется сказать "прощай".

А при SHBO я так понимаю для каждого ресторана надо свой SH? Или часть (с одинаковым меню) по вышеописанной схеме. Тогда придется сказать "прощай" заведению накладных одним рестораном для другого (понимаю, что это неправильная схема, но все-же у нас любят на одного человека повесить несколько ресторанов)? Или для каждой базы еще доп. рабочие места. Какой вообще функционал у этого SHBO? ТОлько отчеты? Или в нем тоже можно работать со справочниками и накладными? А доп. рабочие места для него тоже есть?

[SH]

Это франшиза. Я не знаю насколько он используется в центральном офисе-мне прислали только файл .TDB. Я его загрузил и больше никаких настроек по синхронизации с ЦО не делал-по ходу его не особо используют, только для выгрузки меню.

Если потом будут еще выгрузки, то 1% собственных исправлений выйдет боком. При использовании RBO делать какие-то изменения самостоятельно нельзя. Никогда. Без исключений.

---------- Добавлено в 01:50 ---------- Предыдущее сообщение было размещено в 01:45 ----------

при SHBO я так понимаю для каждого ресторана надо свой SH?

Да, если использовать выгрузку расхода из отчетности RKBO.
В общем, забудьте, что я говорил про SHBO, лучше не надо, по-крайней мере, надо консультироваться с UCS
Я пытался так:
- RKBO выгружает меню по точкам;
- собираю энддейи с точек, кидаю в общие отчеты (обычные, не RBO);
- в SHBO загружаю меню из RKBO;
- в базу SH загружаю словари из SHBO;
- в базу SH загружаем расход из общих отчетов.

Но у меня что-то где-то пошло не так, в итоге база SHBO оказалась убита. Там шаг влево - подрыв на месте без предупреждения.

---------- Добавлено в 01:53 ---------- Предыдущее сообщение было размещено в 01:50 ----------

Какой вообще функционал у этого SHBO? ТОлько отчеты? Или в нем тоже можно работать со справочниками и накладными?

В первую очередь, он нужен для создания общих справочников, по которым надо строить общие отчеты.
Но официальная идеология - "на каждую точку в RBO своя база SH". Это мне очень сильно не понравилось. По хорошему, вопреки описанной мной выше схеме, правильно должно быть так:
- отчеты с точек в отчеты RBO
- расходы в SH из отчетов RBO.

По-хорошему, надо эксперементировать, проверять.

А доп. рабочие места для него тоже есть?

Кажется, там просто нет ограничений на рабочие места.

[olegash]

При использовании RBO делать какие-то изменения самостоятельно нельзя. Никогда. Без исключений.

Это понятно. Но мне никаких инструкций на этот счет не поступало-значит можно исправлять.

В общем, получаем копию ark6.udb локально, папку db с меню также синхронизируем и можно делать импорт.

Тогда получается можно еще эту базу и к RK подцепить и смотреть отчеты. А в каком, кстати отчете в SH можно посмотреть взаиморасчеты с контрагентами-кто кому, чего должен?

---------- Добавлено в 02:07 ---------- Предыдущее сообщение было размещено в 01:55 ----------

Но у меня что-то где-то пошло не так, в итоге база SHBO оказалась убита. Там шаг влево - подрыв на месте без предупреждения.

Ну если у таких профи косяки с этим SHBO, то мне по-ходу вообще лучше не соваться в эту тему. Но клиент имеет очень большое желание перевести все свои точки на централизованный учет с единой CRM (кстати UCS-овскую новую CRM никто не пользовал?) . Тем более у него еще куча бильярдных и кинотеатр. Им презентовали iiko-по их словам им все понравилось. И там есть нормальный централизованный учет (опять же с их слов и по рекламе в инете). Мне надо их убедить, что RK лучше, но по всей видимости это не так.

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

по-крайней мере, надо консультироваться с UCS

Нет уж лучше я здесь. Или я не с теми людьми там общаюсь. У меня иногда такое ощущение, что они сами не знают, как это все работает.

[SH]

в каком, кстати отчете в SH можно посмотреть взаиморасчеты с контрагентами-кто кому, чего должен?

Скорее всего, Вам нужен раздел "Бухгалтерия", а далее "Баланс по корреспондентам" и "Сроки оплаты накладных".

там есть нормальный централизованный учет

Он там есть. И неплохой. Для кафешки сойдет. Для сети - ... промолчу.

Им презентовали iiko-по их словам им все понравилось.

iiko вообще прекрасно выглядит на презентациях.

Двойной учет нужен?
В общем-то, проблема не в выборе программы. Проблема во внедрении. Если продавец iiko о внедрении молчит - значит, он им заниматься не хочет. Или боится объявить цену, чтобы не спугнуть клиента. Потом что нормальное внедрение может стоить больше, чем стоят лицензии - и это нормально. И "пуско-наладка" - это не внедрение.

15 ресторанов - это по 100 с точки, так, навскидку. То есть порядка полутора миллионов за работы. Я брал за один объект, большой, правда, 150 тысяч в месяц. Ушло три месяца. Сейчас уже полтора года работают, как на рельсах. Но мало кто так готов платить. А результат (плохой) потом сваливают на программу.

---------- Добавлено в 02:18 ---------- Предыдущее сообщение было размещено в 02:16 ----------

Или я не с теми людьми там общаюсь. У меня иногда такое ощущение, что они сами не знают, как это все работает.

Здесь на форуме бывает count, Григорий Плетнев. Советую к нему обратиться, в т.ч. попытаться его спросить при звонках в UCS. У него большой опыт работы с бэкофисом.

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

если у таких профи косяки с этим SHBO

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

клиент имеет очень большое желание перевести все свои точки на централизованный учет с единой CRM

Я несколько лет назад делал единую CRM для сети ресторанов, без всяких бэкофисов. Задача была - именно строить разнообразные отчеты по сети. Сделали сбор данных из кипера, хауса и 1с, плюс дополнительные данные, которые в Excel'е вели, и потом заказчик мог их крутить, как хотел.

И в общем-то, это стоит не сильно дорого и получается под заказчика, именно так, как хочется, без каких-либо ограничений.

[olegash]

А вот еще вопрос такого плана. Т. к. меню было загружено из RBO, соответственно в нем удаленных блюд больше чем рабочих. Соответственно при импорте в SH все они оказались в папке удаленные. Это наверное как-то мешает работе базы (лишний мусор и путаница). Хотел почистить меню в RK с помощью утилиты (забыл как она называется, стандартная UCS -овская). Но в свете кривости структуры БД RK (у нас постоянно проблемы при выгрузке в 1С) - побоялся, как бы там новые блюда чего не затерли. Или в связке с SH4 можно без проблем?

[SH]

olegash, если уже сделали выгрузку в SH4 - удалять уже крайне не желательно. Хотя в Вашем случае проблем быть не должно. Будут некоторые шифры в хаусе, которые останутся лежать невостребованными. Как только на этот шифр будет новое блюдо в кипере - в хаусе после импорта тоже будет "подниматься", но раз истории нет, калькуляций нет... Вроде должно быть нормально все.
Можно попробовать:
- почистить базу кипера (файлики menu_.db и modify_.db заменить на чистые);
- завести в кипере новое блюдо;
- сделать импорт в хаус и посмотреть. Если все нормально - то и далее должно быть нормально.

[olegash]

И "пуско-наладка" - это не внедрение.

Абсолютно с вами согласен. Но в основном (за всех не буду говорить, по крайней мере я (пока на большее не хватает знаний\опыта), продаем программу, а не решение и устанавливаем ее. А внедрение и постановка бизнес процессов на предприятии стоит реально больших денег. Тем более сети предприятий.

[SH]

А внедрение и постановка бизнес процессов на предприятии стоит реально больших денег. Тем более сети предприятий.

Вот о том и речь. Но те, кто дает денег, считают, что достаточно купить молоток и дом построиться сам.
Поэтому если автоматизацию начинают не с поиска внедренцев, а с разговора "какая программа лучше" - проект обречен.